• State Suggested Answer
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 75 subscribers
  • Views 841 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 266980
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Setup a Debug environment on Segger Embedded Studio using ARM GCC tools

ppillai

We are currently developing for a product that uses the nRF52832, using Segger Embedded Studio (SES) 4.52c, and the ARM GCC toolchain (2019 q4 version. 

We have set up an SES project to build using ARM GCC, and this is successful. We have no issues with the release executable. Our issue is with Debugging. In BLE-enabled projects, if breakpoints are hit, the session becomes unstable and it may stop with the code appearing to run to sections of memory that the SoftDevice resides in. There are also issues where breakpoints are enabled on sections of code that are definitely being encountered, but breakpoints set there are never hit. 

There is obviously something wrong with our debug configuration, and I was hoping someone could point me to instructions or a HOW TO if someone has set up a Debug Environment in the same way we wish to. Versions being the same are not very important. 

Parents
  • 0

    Basically, is correct. 

    Once the softdevice is enabled and started, you can't use normal breakpoints, because the softdevice will miss time critical events. It is possible to use Monitor Mode Debugging, but this is not something that I have tested myself. My typical advice is to use logging and reset the application after breakpoints. It takes a bit longer, but that is how it is working with embedded devices and (time sensitive) protocol stacks.

Reply
  • 0

    Basically, is correct. 

    Once the softdevice is enabled and started, you can't use normal breakpoints, because the softdevice will miss time critical events. It is possible to use Monitor Mode Debugging, but this is not something that I have tested myself. My typical advice is to use logging and reset the application after breakpoints. It takes a bit longer, but that is how it is working with embedded devices and (time sensitive) protocol stacks.

Children
No Data
Related
Terms of service