Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Re-connecting JLinkExe each time after flashing the device

I have a problem when using JLinkExe + JLinkRTTClient. My operating system is Ubuntu 18.04, and I compile the project using cmake and gcc (using great helper scripts from nRF5-cmake-scripts).

Recently I have updated to SDK v. 17, I do not know if that is related, and also I have updated Nordic Command Line Tools from version 10.6.0 to the latest 10.12.1.

The problem now is that if I launch the JLinkExe and JLinkRTTClient with nRF52840 chip connected via SWD, I can correctly see the initial output of my application in JLinkRTTClient, and I can check that it send it again by hardware resetting it.

The problem is that after I re-flash using nrfjprog the chip (either application only, or application + softdevice + bootloader), the JLinkRTTClient stops showing any output. To restore correct operation, I either have to re-launch JLinkExe + JLinkRTTClient, or type "connect" command in JLinkExe so that it reconnects again - after that I see the output in JLinkRTTClient again.

What can be the cause of the problem?

In the attachments below are my configuration files (app_config.h and sdk_config.h).

Parents
  • Hello,

    Are you re-programming the device with the exact same FW? If not, you will likely have to re-connect the debugger in order for j-link to correctly locate the new RTT buffer in RAM (buffer is not linked to a fixed address).

    Best regards,

    Vidar

  • Hello!

    Yes, I have double checked that right now - I launch the same cmake target that does the flashing after build, and It does not re-build the target each time (only the first time), so the compilation and linking are done only once - but the same effect is observed.

    I think that hex-generation, hex-merging, dfu page generation are some of the operations that are repeated on each target run.

    Below are the cmake output of the "merged" target (the one that flashes everything - app, softdevice and bootloader)

    ====================[ Build | ConMod_bl_sd_app_merge_flash | Debug-arm-none-eabi ]====
    /snap/clion/137/bin/cmake/linux/bin/cmake --build WorkDir/Nordic/connectionModule2/cmake-build-debug-arm-none-eabi --target ConMod_bl_sd_app_merge_flash -- -j 3
    [  7%] Built target uECC
    [ 97%] Built target ConMod
    [ 98%] Generating ConMod_bl_sd_app.hex
    
    Note: Generating a DFU settings page with backup page included.
    This is only required for bootloaders from nRF5 SDK 15.1 and newer.
    If you want to skip backup page generation, use --no-backup option.
    
    Generated Bootloader DFU settings .hex file and stored it in: WorkDir/Nordic/connectionModule2/cmake-build-debug-arm-none-eabi/src/ConMod_bootloader_setting.hex
    
    Bootloader DFU Settings:
    * File:                     WorkDir/Nordic/connectionModule2/cmake-build-debug-arm-none-eabi/src/ConMod_bootloader_setting.hex
    * Family:                   NRF52840
    * Start Address:            0x000FF000
    * CRC:                      0x37F474AB
    * Settings Version:         0x00000002 (2)
    * App Version:              0x00002710 (10000)
    * Bootloader Version:       0x00000001 (1)
    * Bank Layout:              0x00000000
    * Current Bank:             0x00000000
    * Application Size:         0x000484B0 (296112 bytes)
    * Application CRC:          0x6C546623
    * Bank0 Bank Code:          0x00000001
    * Softdevice Size:          0x00025634 (153140 bytes)
    * Boot Validation CRC:      0xACDA1BA2
    * SD Boot Validation Type:  0x00000000 (0)
    * App Boot Validation Type: 0x00000000 (0)
    
    Parsing input files.
    Merging file "bootloader.hex" into output.
    Merging file "ConMod_bootloader_setting.hex" into output.
    Merging file "s140_nrf52_7.2.0_softdevice.hex" into output.
    Merging file "ConMod.hex" into output.
    Storing merged file.
    Bootloader: FLASH=23984 RAM=22160
    Softdevice: FLASH=155648 RAM=33157
    Firmware: FLASH=291088 RAM=191160 (heap: 16384, stack: 16384, firmware: 158392)
    Total: FLASH=470720 RAM=224317
    RAM   |##################################      |  85 % 
    FLASH |#################                       |  44 % 
    [100%] Built target ConMod_bl_sd_app_merge
    Connected devices:
    0: 483066362
    
    # Programming ...
    nrfjprog -s 483066362 --program WorkDir/Nordic/connectionModule2/cmake-build-debug-arm-none-eabi/src/ConMod_bl_sd_app.hex --chiperase
    # Resetting ...
    nrfjprog -s 483066362 --reset
    [100%] Built target ConMod_bl_sd_app_merge_flash
    
    Build finished
    
    

    P. S.

    I forgot the link in the original post to the nRF5-cmake-scripts repository that I use to build my project.

  • Hello,

    I looked through the release notes for nrfjprog and found this for the 10.10.0 release:

    (nrfjprog.dll) Fixed bug where nrfjprog did not correctly handle debug power. NRFJPROG_close now always ensures that debug power is disabled.

    So I suspect this is the problem: nrfjprog turns off the debug power even if Jlink commander is connected and thus breaks the SWD connection to Jlink commander.

    Note that leaving the debug interface powered will lead to increased current consumption (~3 mA in idle).

  • Ok, thank you for the explanation!

    So, if I understood it correctly, that means that this is by design, and now I have to re-connect J-Link manually like that? So, this behavior is expected?

    It is not that I cannot work like that, it just a little annoying.. Maybe there are some way to tell running JLinkExe to reconnect, e.g. by a bash command, such that it automatically re-connects each time I flash th device?

  • Yes, it's by design. I'm not aware of any commands to make Jlink commander automatically re-connect, unfortunately, but maybe the -AutoConnect option could make the re-connect process a bit less annoying.  Alternatively, as workaround, you may try to downgrade to an older version of nrfjprog during development.

  • Ok, I will look at -AutoConnect option,

    Thanks a lot for the help!

Reply Children
No Data
Related