Several issues with nRF Connect for VS Code

Hello,

I have several issues with the new nRF Connect for VS Code SDK, I put them into one ticket, although, some of the issues could be related directly to nRF Connect SDK, not the VS Code plugin. I have latest nRF Connect SDK, latest VS Code and using nRF52840 SoC

  1. RTT is unreliable - in 80% cases of debugging, the RTT output is blank. And even if it works, the output is "damaged", like my printk and zephyr boot message is mangled together. Also, when something crash inside the kernel, or assert is called, nothing is shown on RTT console, and also debugger not break on problem. (NOTE: I had higher success by manually using RTT via JLink.exe than the one integrated in VS Code)
  2. It's uncertain what all the "Debug" action do. Does it build the firmware if there are any modifications? Does it flash firmware? About flashing firmware, yes, it flashes it, but it's nowhere clarified that Flash is being made, so it can be confusing for developer and he can instead execute Flash action and then Debug, which is adding additional time to debug.
  3. When creating launch.json, the first created configuration "Launch active build configuration" is not working, it throws error that "nRF Connect: Build active configuration" task doesn't exists.

The 1. issue is most critical one, because at the moment, it's very hard to find out why the app is crashing. Other ones are just bugs or some improvements.
Although, besides those things, VS Code extension is pretty good and it's way better experience than working with SES, thank you for your hard work.

This is my prj.conf:

# nothing here
CONFIG_CONSOLE=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_UART_CONSOLE=n

CONFIG_NRFX_GPIOTE=y
CONFIG_LOG=y
CONFIG_MULTITHREADING=y
CONFIG_GPIO=y
CONFIG_ASSERT=y
CONFIG_LOG_PRINTK=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG2_MODE_DEFERRED=y


CONFIG_DEBUG_OPTIMIZATIONS=y
CONFIG_DEBUG_THREAD_INFO=y

Thanks,
with Regards,
Marek Kraus

Parents
  • Dear Nordic,

    To my first issue about RTT, I figured out how to get it working.
    Firstly, I configured CONFIG_LOG_MODE_IMMEDIATE=y , after that, run the firmware and after that open RTT console.
    Although, sometimes when I close and re-open RTT terminal, the RTTClient doesn't run at all and restart of VS Code is required.

    I think this issue is because of combining various apps using the JLink, like there is active RTT connection, then nrfjprog spawns new JLink.exe, then Debug spawns JLinkGDBServer etc.

    From my personal experience, to get reliable Flash, Debug and RTT Console, is after every build to launch JLinkGDBServer, GDB connects and flash firmware, and while all this is happening, the JLinkRTTClient is executed and connected to GDB Server (or just direct Telnet which I found more reliable to use). When using this, I never got any issues with RTT (only delayed messages, but this also happens right now in VS Code).

  • Hi Marek,

    RTT is unreliable - in 80% cases of debugging, the RTT output is blank. And even if it works, the output is "damaged", like my printk and zephyr boot message is mangled together. Also, when something crash inside the kernel, or assert is called, nothing is shown on RTT console, and also debugger not break on problem. (NOTE: I had higher success by manually using RTT via JLink.exe than the one integrated in VS Code)

    Glad that you got it working. There are a few small issues which we are working on and will try to ease out in the future updates. 

    • It's uncertain what all the "Debug" action do. Does it build the firmware if there are any modifications? Does it flash firmware? About flashing firmware, yes, it flashes it, but it's nowhere clarified that Flash is being made, so it can be confusing for developer and he can instead execute Flash action and then Debug, which is adding additional time to debug.

    Debug does build the firmware in case of modifications and flashes it onto the board. Thank you for the feedback and we will try to clarify that it is being flashed too before Debug. Slight smile

    When creating launch.json, the first created configuration "Launch active build configuration" is not working, it throws error that "nRF Connect: Build active configuration" task doesn't exists.

    This might be a bug and could you try removing the "preLaunchEntry" property from your launch.json file?

    Kind Regards,

    Priyanka

Reply
  • Hi Marek,

    RTT is unreliable - in 80% cases of debugging, the RTT output is blank. And even if it works, the output is "damaged", like my printk and zephyr boot message is mangled together. Also, when something crash inside the kernel, or assert is called, nothing is shown on RTT console, and also debugger not break on problem. (NOTE: I had higher success by manually using RTT via JLink.exe than the one integrated in VS Code)

    Glad that you got it working. There are a few small issues which we are working on and will try to ease out in the future updates. 

    • It's uncertain what all the "Debug" action do. Does it build the firmware if there are any modifications? Does it flash firmware? About flashing firmware, yes, it flashes it, but it's nowhere clarified that Flash is being made, so it can be confusing for developer and he can instead execute Flash action and then Debug, which is adding additional time to debug.

    Debug does build the firmware in case of modifications and flashes it onto the board. Thank you for the feedback and we will try to clarify that it is being flashed too before Debug. Slight smile

    When creating launch.json, the first created configuration "Launch active build configuration" is not working, it throws error that "nRF Connect: Build active configuration" task doesn't exists.

    This might be a bug and could you try removing the "preLaunchEntry" property from your launch.json file?

    Kind Regards,

    Priyanka

Children
No Data
Related