How to debug lwm2m_client sample on Thingy91 development kit?

Our company is in the process of developing a new IoT product for LTE-M and NB-IoT. The sample application lwm2m_client runs fine on our devkits nRF9151DK & Thingy91 and connects fine with Leshan, AVSystems and nRFCloud. UART console of both devkits show a lot of shell outputs. So far so good.
Past days I had to debug an issue but depending on some conditions I didn't know some times I could easily SWD debug and sometimes not. In the end I found this out:

  • nRF9151DK both standard builds and debug-build configs run just fine on those boards, UART output is correct.
  • Thingy:91 (nRF9160):
    • standard builds work both via MCUBoot-Update and via SWD debugger. In the debugger I can single step and run and the app run fine.
    • debug builds for the Thingy/nRF9160ns target (-Og, -DCONFIG_DEBUG_THREAD_INFO=y) dont work, dont show UART outputs, even the blinky sample is doing nothing
    • debug builds for the Thingy/nRF9160 target (no ns, -Og, -DCONFIG_DEBUG_THREAD_INFO=y) work, show UART outputs, but this is only valid for very simple MCU-like applications. Using the no-ns build target is preventing applications which require the LTE modem (TP-M)

Currently I'm out of ideas how I can debug an application using the LTE modem on the Thingy91 platform. Whats the supposed way to go in May 2025?

Parents
  • Another data point:

    When I flash the merged.hex of a non-debug blinky build to the Thingy:91 via SWD, everything works fine — UART output appears and the LED blinks. Then I press the button, power-cycle the board, and end up in MCUboot. From there, I use the nRF Connect Programmer to flash zephyr.signed.hex from the debug build. After that, nothing works — no UART output, no LED activity.

    I press the button again, power-cycle once more, and this time flash the zephyr.signed.hex from the non-debug build — and the LED starts blinking again.

  • Any idee how a thingy:91 with LTE modem active can be debugged in 2025?

  • Hi,

    I suggest that we start from very beginning, looking at what does not work as expected. For example, you mentioned

    cellular_iot said:
    Blinky on nrf9151DK_nrf9151ns: all versions work including debugging

    Can you provide detailed steps and screenshots to reproduce this (starting from build command you used)?

    Best regards,
    Dejan

  • Ok, lets first show the good version using the nRF9151DK:
    New VSCode Window:

    create new app, copy sample from "nrf/samples.../blinky"



    created in c:\blinky


    nrf connect/application/blinky/add build configuration:
    - sdk & toolchain v3.0.1
    - board: nrF9151dk/nRF9151/ns
    - prj.conf
    - optimize for debugging (-Og)
    - Build directory name: build_51_dbg


    - click: generate and build, wait several minutes on my 16 Core i7-1360p
    - build OK:

    Click on actions/debug
    - some west magic, flashing, debugg view loads

    I can single step using F10:

    Serial terminal is showing blinky Uart output:

    LED1 is blinking

  • Now the good version using Thingy91.


    Lets create a non debug in build_60:



    flash it:

    It blinks and UART output is working:



  • Now lets create and build a thingy91 debug version:

    And  lunch the debugger:

    Now the CPU doesnt hit the apps main():

    single stepping is not working:


    Oh wow, after several atempts to F10/F5 this time I get a blinking board and a UART output:

    - but the call stack is not showing app threads and I cannot single step

    After stopping the debugger, reflashing, attach debugger it looks like this - that the exception/assertion I see most often when I try to debug the lwm2m_client sample on the thingy91:


    And what helps reliably is to disable "optimize for debug (-Og), use -Os and manually add cmake argument -DCONFIG_DEBUG_THREAD_INFO=y

  • when I try to debug the sample lwm2m_client, it works as expected on the nRF9151DK and not on the thing91, mostly the CPU spins endless in the "flash is not locked" assertion like here:



    So it looks like the larger the app the higher the chance the debug setup is breaking

Reply Children
No Data
Related