This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

RTT not working in saadc example

NRF52832

SDK 17.0.2

SoftDevice 132

I am connecting with telnet to an exposed RTT port to see the logs. I adjusted sdk_config.h to use RTT instead of UART logging.
The setup works for the SDK ble_peripheral/ble_app_blinky example, i.e., I can see all the logged statements in my telnet session. 

However, after programming the peripherals/saadc example, I am not able to see any logs. With gdb I can confirm that NRF_LOG_FLUSH() is being called. Reflashing the softdevice also didn't solve the issue.
Do you have any idea of what I might be missing?

Parents
  • Hello,

    Please try to power-cycle the board to see if resetting the RAM makes any difference. I wasn't able to replicate the problem with the peripherals/saadc sample here. All I did was to enable the NRF_LOG_BACKEND_RTT_ENABLED setting.

  • I see. Restarted the MCU several times -> always the same issue.

    Truth be told, I do not use a developer board nor a JLink debugger -> so I assume this is related to my custom setup:
    I attached SWDIO, SWDCLK, VCC and GND to a Raspberry 3 and use openocd to program + setting up RTT server. 
    All works perfectly fine for the ble_peripheral/ble_app_blinky example, i.e., I can see the log output via telnet and can use nrf connect app to connect and interact with the service. 

    Maybe I should go a more "supported" way and get my hands on a JLink debugger. Can you confirm that the JLink BASE Compact is sufficient to be fully compliant with nrf52 requirements? www.segger.com/.../

  • In the RTT setup, do you specify an address range of where the RTT control block is located? I haven't used openocd much myself so I'm not sure how it works, but the Control block will get placed lower in RAM when you have a smaller application like the SAADC example running on the device.

    Yes, Jlink BASE has the needed features to work with the nRF52. Note that you can also use the Jlink lite which comes on the Nordic development kits for programming of external boards (see Debug output. Note target board must have the same VDD voltage as the DK). 

Reply
  • In the RTT setup, do you specify an address range of where the RTT control block is located? I haven't used openocd much myself so I'm not sure how it works, but the Control block will get placed lower in RAM when you have a smaller application like the SAADC example running on the device.

    Yes, Jlink BASE has the needed features to work with the nRF52. Note that you can also use the Jlink lite which comes on the Nordic development kits for programming of external boards (see Debug output. Note target board must have the same VDD voltage as the DK). 

Children
  • Good idea. My understanding is that the linker script determines the RAM start address and the RTT control block is located close to the RAM start. For saadc, I have the following memory section declared:

    MEMORY
    {
        FLASH (rx) : ORIGIN = 0x0, LENGTH = 0x80000
        RAM (rwx) : ORIGIN = 0x200022f0, LENGTH = 0x10000
    }

    I.e., my RAM starts at 0x200022f0. I adjusted the control block search accordingly in my openocd script:

    rtt setup 0x200022f0 0x3000 "SEGGER RTT"

    When I program the MCU and connect via gdb, I can see:

    rtt: Searching for control block 'SEGGER RTT'
    rtt: Control block found at 0x20002f14

    Still, I am not seeing any log output in telnet for the saadc example. I am stuck on this now since quite some time and I am not sure if this is related to openocd, my custom board or my inexperience. So I think moving to an officially supported toolchain is the easy way to at least rule out openocd as a source of err.

    Thank you for the hint with programming via DK. Looks interesting! Out of curiosity: are there some limitations between JLink lite in DK and JLink base? Why is one much more expensive than the other?

  • fishi0x01 said:
    Still, I am not seeing any log output in telnet for the saadc example. I am stuck on this now since quite some time and I am not sure if this is related to openocd, my custom board or my inexperience. So I think moving to an officially supported toolchain is the easy way to at least rule out openocd as a source of er

    I agree, it may have something do to with the RTT support in openOCD. I'm not able to replicate the issue with Jlink at least.

    fishi0x01 said:
    Thank you for the hint with programming via DK. Looks interesting! Out of curiosity: are there some limitations between JLink lite in DK and JLink base? Why is one much more expensive than the other?

     I guess it is because the Jlink lite has some license restrictions. For instance, it does not allow you to target non-Nordic devices. Also, as noted above, it does not have a built-in level shifter so your target board needs to have the same supply voltage as the Development board.

Related