• State Not Answered
  • Replies 3 replies
  • Subscribers 96 subscribers
  • Views 631 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 297260
Options

VS Code debugging not behaving properly

Kyrre Aalerud

It seems like VS Code debugging will reset debugger if you click to reset MCU. This somehow leads to it dropping RTT.
It further releases the CPU while reconnecting and halts the processor somewhere in init or idle loop of Zephyr depending on how slow it was to complete.
Most of startup information is thus lost as RTT was not read and became full.

Flashing of the device is also horribly slow, and sometimes fails to connect debug after flashing.
There also does not seem to be a way to connect to target for debug without reflashing.

1. Why not keep cpu properly in reset until ready to debug like Segger Studio used to do.
2. Why not keep RTT connected to receive all debug output.
3. How to speed up flashing
4. How to connect to debug target without reflashing

Parents
  • 0

    Hi,

    What hardware are you connecting?

    Do you experience the slow flashing with all samples or just some?

    What do you mean by connecting to target without reflashing? Do you have to click flash again before you are able to debug? 

    What version of the extension are you using? and what version of VS code?

    Regards,
    Jonathan

  • 0 in reply to JONATHAN LL

    VS Code is 1.72.2 and nRF pack is v2022.9.6 and we connect to nRF5340 board with similar setup to original DK using DK as programmer.
    In Segger Studio everything is fast, and was working fine (although segger has horrible code lookup, possibly from too low bits hash table?). Changing to SDK 2.1.0 with Segger no longer supported, we are forced to use VS Code.

    With Segger Studio, you were able to reconnect to a device you already flashed and that had been running. There was a choice between just connecting or flash the unit and reset it. This option appears missing.

    In addition, hitting reset processor from debugger appears to loose connection to RTT which then has to be re-established after running target again. This looses valuable data during boot (when debugging boot). In Segger Studio this connection was re-established and no data was lost. It also reset mcu properly and connected debugging with halted cpu at reset vector properly. With VS Code the system appears to "run away" during reset before debugger catches up.

Reply
  • 0 in reply to JONATHAN LL

    VS Code is 1.72.2 and nRF pack is v2022.9.6 and we connect to nRF5340 board with similar setup to original DK using DK as programmer.
    In Segger Studio everything is fast, and was working fine (although segger has horrible code lookup, possibly from too low bits hash table?). Changing to SDK 2.1.0 with Segger no longer supported, we are forced to use VS Code.

    With Segger Studio, you were able to reconnect to a device you already flashed and that had been running. There was a choice between just connecting or flash the unit and reset it. This option appears missing.

    In addition, hitting reset processor from debugger appears to loose connection to RTT which then has to be re-established after running target again. This looses valuable data during boot (when debugging boot). In Segger Studio this connection was re-established and no data was lost. It also reset mcu properly and connected debugging with halted cpu at reset vector properly. With VS Code the system appears to "run away" during reset before debugger catches up.

Children
Related
Terms of service