Posts by zainka

    Hi

    I have a problem related to connecting an jlink EDU to linux, Jammy, Ubuntu 22.04.3 LTS
    The jlink does no longer enumerate correctly when attaching.
    Basically it fails with "Device not responding to setup address.", but the whole enumerate process is reffered below.

    Right now I do not have any other computer to test with, but will do as soon as possible, but have anyone had similarissues and solutions?
    I cant reflash offcourse since it does not enumerate.But, I opened upthe device and noticed it is an SAM7 device of which I have Atmels own programming tool
    I may therefor reprogram if required directly, i guess.

    Thanks in advance

    Heres how I fix.
    The bundle install script.. st-stm32cubeide_1.0.1_3139_20190612_1256_amd64.deb_bundle.sh ..
    creates a temp folder with the same name as the bundle script + .root at the end, and located in the same folder as the install script. Here the install script extracts the bundled deb packages including segger-jlink-udev-rules-6.44c-3-linux-all.deb.

    Folder content
    segger-jlink-udev-rules-6.44c-3-linux-all.deb
    setup.sh
    st-stlink-server-1.2.0-3-linux-amd64.deb
    st-stlink-udev-rules-1.0.0-linux-all.deb
    st-stm32cubeide_1.0.1_3139_20190612_1256_amd64.deb
    -------

    The script setup.sh runs the deb packages using command
    dpkg --refuse-downgrade -i *.deb

    By changing this command in the script before it is running by adding --force-all , the script will succeed installing the rules.
    dpkg --refuse-downgrade -i --force-all *.deb


    One problem though, this folder with script and deb packages are auto generated and removed right after execution.
    You need to halt installation process before this happens, but after the unpacking of the bundle

    This may be done simply by adding --confirm as an option when running the install script

    $ sudo ./st-stm32cubeide_1.0.1_3139_20190612_1256_amd64.deb_bundle.sh --confirm


    The script will then ask when it is about to run the setup.sh script for your confirmation to extract the bundle

    > About to extract 648940 KB in st-stm32cubeide_1.0.1_3139_20190612_1256_amd64.deb_bundle.sh.root ... Proceed ? [Y/n]

    Hit Y to proceed.The bundle is extracted. Then the script asks for permission to execute.:

    > OK to execute: ./setup.sh ? [Y/n]

    When it does, WAIT and do NOT continue, but leave it alone for a while and use your favorite text editor and enter the folder named st-stm32cubeide_1.0.1_3139_20190612_1256_amd64.deb_bundle.sh.root

    It will be in the same folder as where your install script is located

    ...And then open setup.sh as root (!) and edit the dpkg command and save

    $ cd st-stm32cubeide_1.0.1_3139_20190612_1256_amd64.deb_bundle.sh.root
    $ sudo vi setup.sh

    edit --> dpkg --refuse-downgrade -i --force-all *.deb

    Now go back to the install window and continue.
    You will get some warnings, but the rules will install fine

    I have this question too, I have large projects where I have been using code::blocks. Since there are no C::B import module, importing blocks of files is a pure necessary for me to be able to switch to SES. I tried on a smaller project to import files one by one, but then I noticed that what SES really did was making a copy of the files in the project root thus destroying my old project structure. Not good. Please tell me that I have missed something crucial here.

    Thanks

    Currently checking out Ozone version 2.52d
    Using jLink EDU and thus just the eval.

    The device is STM32F407VGT

    Everything works fine but i noticed that the peripherals register view only shows USART 1, 2 and 6. The others are gone.
    The correct device is set

    Project.SetDevice ("STM32F407VG");

    And the following SVD files are loaded

    Project.AddSvdFile ("Cortex-M4F.svd");
    Project.AddSvdFile ("/opt/SEGGER/ozone/2.52.4/Config/Peripherals/STM32F407IG.svd");

    Is this a known limitation or even a bug? I was intended to look at some code using USART3 and check that the registry was set correctly, but .... :S

    I noticed that only one SVD file for 407 was available and it has the IG and not the VG extension. But according to datasheet for 407 they should all have all the 6 USART/UART's available, so I do not think this should be an issue.

    From datasheet:
    "The STM32F405xx and STM32F407xx embed four universal synchronous/asynchronous
    receiver transmitters (USART1, USART2, USART3 and USART6) and two universal
    asynchronous receiver transmitters (UART4 and UART5)."

    Best regards
    Vidar

    Hi

    I have been trying to use the linux IDE, DDD (data display debugger) together with my jlink. However, it seems that DDD is passing some wrong options to the debugger when it is invoked. This is -g and -fullname options which i believe is supported by gnu debuggers. I wonder if anyone has been able to use DDD with jlink or if there is any other light IDE's around which does and which could run on Slitaz. (By light I mean NOT eclipse but it should have possibilities like separate panes for code and memory for example).

    The following shows the DDD log. It does not say to much so any help would be appreciated. I also tried to invoke DDD with option -JDB but this does not help (kinda hoped it meant "jlink debugger")

    Just a final status update before I rest my case. At em::blocks forum others have now confirmed that they face the same issue with their own project. I have also filed a ticket at em::blocks which hopefully will trigg a patch soon. For me I simply use version 1.45 for now as it works as expected with this version.

    The previous mentioned problem with 1.45 and of which I knew a solution for was related to the debugger ignoring that custom makefiles might not put the elf file in the default obj folder. The solution for this can be found nested in my posts at em::blocks forum, if anyone is interested, but later versions of em::blocks has that spesific issue fixed permanently.

    Therefor, if you do not have any special interests in the topic dont waste time on it since you seem to be occupied anyway. Good luck with the Embedded World and thanks for your help so far.


    Vidar

    Hi Thanks for your answer.

    I have had some discussion with the em:blocks team but they know no issues which could explain the behavior, but my experience is that there are some issues with em:blocks regarding projects using custom makefiles as i do when it comes to where and how the debugger finds and handles the code. Never the less I added there an example project which I hope someone will either find some issues with which means I have done something wrong or they will find other issues with em:blocks that could cause troubles as mine.

    I no longer, and did not, expect to find any issues with the segger sw.

    Regarding your questions, the first thing I suspected to be wrong was off course my own setup. And I have had many tests and recreations of my project setup before I turned to the forums for help. Never the less, the project did not change between when it worked with my older windows environment and until I re-stored my windows and installed em:blocks 2.30. Have as few changing parameters as possible between checkpoints is a key to success.

    However, I have tried other sw like emIDE and I had no problem setting up my environment there, and as mentioned I had it somewhat working with emblocks 1.45 earlier, which I had a copy of after installing windows again, but where I run into other issues which of I know the solution for. It was when installing emblocks 2.30 I run into problems.

    I might switch to emIDE permanently if I find no solution but I have other projects setup for emblocks and you know, one is often reluctant to change environment to often.

    Never the less, I have uploaded a project where I have the issues as mentioned. Feel free to look into the issue but dont waste your time if you do not need to.

    Thanks in advance

    Vidar

    After reverted my windows with a clonezilla image I had to install em:block 2.30 and segger j-link sw version 4.96g. I also then got firmware of my jlonk edu upgraded. However, when I now tries to start my project for debug, which before i reinstalled the windows image worked perfectly every time, em:blocks recompiles as expected but the debugger gdb server is not started.

    I have tried to get some info on em:blocks forum but until now I have not got any replies.

    Thing is, I had em:blocks 1.45 installed in my old windows image and when debugger is started here the gdb server is launched aswell. But not when running from em:blocks 2.30.

    I just wondered if anyone have had any experience with this and found a solution.
    Yes I have followed the guide found under supported IDE's at segger.com but to no help.

    I may start the gdb server manually and it connects to my jlink debugger and waits for connection, but nothing happens when I try to start a debugg session form em:blocks.

    Thanks in advance

    You may find my post at em:blocks forum here:
    http://www.emblocks.org/forum/viewtopic.php?f=19&t=566


    Breg
    Vidar