Posts by Torsten Robitzki

  • [SOLVED] Local Data view is extended to be able to display data type

    Hello,
    first of all, let me say thank you for this great debugger. I switched from GDB after experiencing a lot of crashes. So far, Ozone is stable and serves me well.

    When displaying local data, the corresponding view tries to display the type with up to 512 characters. This extends the main window to span the used monitor multiple times. I know, that 512 is extreme, but using C++ templates, this is not unusual (CRTP). Maybe, it would be an option to have a horizontal scroll bar in the type display?

    best regards

    Torsten

  • J-Link RTT Viewer requires Disconnect / Reconnect

    Hi Alex,
    well I'm not sure, if I really want to understand the inner details of your RTT implementation. According to the white paper on your website, it is basically polling some memory regions via SWD. So from technical perspective, I can not see, why the viewer / JTrace stops polling when there was an error condition, but of cause I'm not familiar with all the necessary details.

    Anyway, my task was to replace a debug UART by RTT, which seems to be not possible, because we would always miss the most important part of the logging, namely the startup.

    Thank you both for your time and the insights into RTT.

    best regards und schönes Wochenende

    Torsten

  • J-Link RTT Viewer requires Disconnect / Reconnect

    Hi Fabian,
    I reset the device in two situations:
    - While flashing new firmware, where the reset is then executed by the JTrace
    - By simply performing a hardware reset (pull nReset to low)

    In both cases, I have to do the reconnect, which is somehow annoying. I do not power down the JTrace, nor do I disconnect the JTrace. To me, this doesn't look like uncommon use cases ;)

    Do you think, this could be improved somehow?

    best regards

    Torsten

    Other observation: When I do some logging with a frequency of 1Hz, I see that log line with a frequency of 0.5Hz being displayed in JLinkRTTViewer

  • J-Link RTT Viewer requires Disconnect / Reconnect

    Hello,
    I have a problem, porting an nRF5340 based Zephyr project from logging to an UART to logging via RTT. I have a J-Trace Pro Cortex-A/R/M connected to a Nordic nRF53. JLink Software Version 7.96c. Maybe someone here has made similar experiences and has an idea as to how to overcome them.

    Observation: Zephyr is configured to use RTT as logging backend. I have small test program, that just writes some log messages. Logging to JLinkRTTViewer stops as soon, as I reset the device. Once, I disconnect and connect again, messages are visible again.

    Is this expected behavior? My Nordic-flavor of Zephyr uses this version of RTT: https://github.com/zephyrproject-rtos/segger

    best regards

    Torsten

  • [SOLVED] Unable to flash a TI LaunchPad CC2652R1FRGZ

    This is a follow up to [SOLVED] LAUNCHXL CC26X2R1 + Code Composer + JLINK EDU MINI unfortunately the thread is closed and I would like to ask the OP how he managed to flash the board, using a JLink. I've removed all jumpers that where not necessary to provide power to the board and connected my J-Trace (using latest SW version V6.72b). JLinkExe just gave similar error messages (trying to reset the board):


    I've attached a logic analyzer and at least saw traffic on the SWDIO and SWDCLK lines. Finally, I gave up and installed the TI software to operate the on board debugger, with which is was possible to install firmware on the board, without any problems (after putting the pulled jumpers back in place). I tried the JTrace after using the TI software once more, but without success.

    Any idea, what could be wrong here?

    Best regards,
    Torsten

  • [SOLVED] unreliable flash upload with J-Trace and SAM4S

    Hi Fabian,
    the J-Trace Pro is less than half a year old. If it helps to speed up this use, I will also open a ticket within your support system. The original message, that flashing with the J-Commander works flawless, was not quite correct. I can see problems there two, but much less. My current workaround is, to close the JLinkGDBServer, start the JLinkExe, flash a new version of the software and then start the JLinkGDBServer again. When flashing with the JlinkExe fails, I try some combinations of `r`, `halt` and `loadfile` until the file is flashed without error message.

    We do not set the SAM4S security flag. Please find attached a hex file that should reproduce the problem. (this more directed to the support, which I will contact right now).

    thanks for looking into this!

    best regards,
    Torsten

  • [SOLVED] unreliable flash upload with J-Trace and SAM4S

    Hi Nino,
    thanks for looking into this. No, it doesn't work (beside the command for reseting seems to be "r" not "reset"). I'm getting reproducible an error while executing the "erase" command:



    As this is deterministic and reproducible, I don't think that this is exactly the issue that is bugging me. I ignored that erase issue and went further down your command list and flashed two different hex files alternating and got no error messages even after at least 10 attempts.

    When writing an elf file using GDB, the GDB Server runs very quickly into the issue I'm seeing (see above). I've attached a log from my JLinkExe session.

    I suspect, that the GDB server is deferring flashing until the CPU is restarted and thus is failing at this point. Are there any other tests, that I can do to bring more insight? Anything to make it more reproducible? (already reduced the SWD frequency).

    best regards,
    Torsten

  • [SOLVED] unreliable flash upload with J-Trace and SAM4S

    Here is a second example:


    I've started GDB (without flash breakpoints enabled, with just one break point set; without the "monitor reset" command from the .gdbinit above). The log showed the messages above down to the last Downloading Message. I've entered a "monitor reset" command, which does not lead to addition log output. After I've started the debug session ("c"), the error message above appeared. The missing T-bit clearly indicates that the flash content was not correct.

    In an other session, the error message above shows up, directly after reseting the controller ("monitor reset"). If I repeat the flash upload (by restating GDB and thus executing the .gdbinit file), I end up without and error messages in the log and then, I'm able to debug my target.

  • [SOLVED] unreliable flash upload with J-Trace and SAM4S

    Hello,
    I'm using a J-Trace Pro to debug an ATSAM4SD32C. While I've tried to figure out, why my code is not doing, what it is supposed to do, I came to the conclusion, that the content of my elf file is not flashed correctly. This is not 100% reproducible but if I inspect for example the interrupt table and compare it with a list file or hex file, I find the address of the Reset_Handler to be "reasonable", but not correct. In the log of the SEGGER J-Link GDB Server V6.54 (GUI Version), I found a clue, that there might have been something wrong:


    The line starting with `ERROR` does not appear, when loading the elf file, but when I start my debug sequence with `monitor reset`. In the cases, where it looks it seems to working correctly, the Error message and the two following lines starting with "RAM" are not present in the log file.

    I've set the "Verify download" option in the GDB server, but even with this option, I don't get any feedback that I can see in GDB (cli version; 7.12.1). This is how my .gdbinit looks like:


    Is there a ways to get reliable around this error / to prevent this error? Is there a way to at least get direct feedback in GDB, that such an error occurred?

    best regards,
    Torsten

  • [SOLVED] starting JLinkExe with command file starts to prompt for input

    Hello,
    I just upgraded by JLink software to version V6.10k on OS/X and this broke my build and test environment. We build and execute jlink scripts based on configured build targets. For example, to erase the flash of a device, we generate a file called erase.jlink and use JLinkExe to execute this file. This worked fine, for the last two years, but now with the new version, JLinkExe starts to propt for additional informations:

    ...
    Please specify device / core. <Default>: NUC140LE3
    Type '?' for selection dialog
    Device>q
    Please specify target interface:
    J) JTAG (Default)
    S) SWD
    F) FINE
    I) ICSP
    C) C2
    TIF>

    Is there a way to get the old behavior back, that is backwards compatible for those team members that do not / can not upgrade to the new version?

    Thanks, in advance and kind regards,

    Torsten Robitzki

    Edit: And I see the same issue with version V6.10k