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

How to get debug information out of the nRF52?

We have an BLE application that we are targeting the nRF52 device for. The application demands using a UART interface to communicate to a host processor. In addition, we typically use a 2nd UART to provide debug output information to let us know what is going on in our SOC device. The problem is that the nRF52 only has one UART peripheral available. We would probably use the single UART to interface to the host processor. However - that leaves a hole as to how to get debug information out of the nRF52 so that it can be monitored. I would think that this would be a common desire. Are there any methods that Nordic has been recommending to their customers to achieve this type of output? If so - what are they?

Parents
  • Using UART for debug information is often not the best choice now. For a start it requires extra connections, if you don't turn it off in production code it runs another peripheral doing nothing useful.

    As John DeWitt says, many people are now using Segger RTT, that just dumps data into a small memory buffer which a connected JLink can read. If nothing reads it, it just stays there. There's also ARM's SWO output, that can pour out data at high speed over one extra pin on the debug connector and is supported by many debuggers. Using SWO is just a case of writing to one memory location, if it's enabled a word is output over SWO, if it's not, it's ignored, so again it can be left in the release code without really mattering.

Reply
  • Using UART for debug information is often not the best choice now. For a start it requires extra connections, if you don't turn it off in production code it runs another peripheral doing nothing useful.

    As John DeWitt says, many people are now using Segger RTT, that just dumps data into a small memory buffer which a connected JLink can read. If nothing reads it, it just stays there. There's also ARM's SWO output, that can pour out data at high speed over one extra pin on the debug connector and is supported by many debuggers. Using SWO is just a case of writing to one memory location, if it's enabled a word is output over SWO, if it's not, it's ignored, so again it can be left in the release code without really mattering.

Children
No Data
Related