• State Not Answered
  • Replies 1 reply
  • Subscribers 67 subscribers
  • Views 4955 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 104363
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Clarify the nRF51822 Debug options

Paul Russell

Please help: Debug is mentioned in many places and is of several types (uart, ble, assert...). I need clarification to distinguish which debug type is in effect, and how to use them. Is there a document or Blog clarifying any of this? Some may be great for diagnostics as well, but I do see some warning in the examples that some types are not recommended for use in final code.

Some of what I did find:

===== details of many debug paths mentioned in docs and examples =====

  • This has several parts, any answers or links appreciated but please indicate the item number you are referring to so as to help all readers.
  1. There seem to be several debug and diagnostic ports in the nRF51822-EK and nRF51822-DK:

1a) Dongle PCA10000 includes both SWDIO and UART between nRF51822 and Segger IC, providing support for onboard debugging through SWDIO (Breakpoints, etc.) and UART (serial data as with a Terminal), as well as BLE communications to EK and DK.

1b) nRF51822-EK PCA10001 also includes both SWDIO and UART between nRF51822 and Segger IC.

1c) nRF51822-DK (set: PCA10004 + nRF6310 + Jlink_Light + dongle) also includes both SWDIO and UART between nRF51822 and [either Segger IC or nRF6310].

1d) Possibly more Debug options by software and tools using virtual ports?

  1. PCA10001 nRF51822 EK

2a) I can step code in Keil, and both nRFgo Studio can program OK, although I'm uncertain which ports are used for which features I believe the SWDIO is used for programming and stepping code.

2b) I haven't had reliable connection using the Segger UART to a Terminal Program. I get binary gibberish with PuTTY set to EK's Segger Com

Port (Com5 for me), 38400, CTS/RTS. Once I did get the "Start:" but it followed with gibberish. I got nothing with RealTerm or TeraTerm. I'm using Win8 64bit.

2c) MCP may be connecting through the Dongle-UART-SeggerVirtualCom to show info of device that is "ble-connected" to the dongle?

2d) Dongle ble_uart (segger vitual comm) may also be used somehow?

2e) Smartphone App nRF UART 2.0 may be supported by some examples (I see some output to smartphone, but input from smartphone not doing much yet).

2f) Which path used for over air upgrade of firmware (sd, application, ...), and is there an app that supports this?

  1. Not sure if nRF51822-DK (PCA10004 DK + nRF6310 + Jlink_Light) has same or more paths than nRF51822-EK?

===== So... =====

  1. Which communication paths are used for what kind of debugging (EK-SWDIO, EK-UART-P0.8~P0.11-SeggerVirtualCom, ble-Donglev220-SWDIO, ble-DongleV220-UART-P0.8~P0.11, nRF6310_???, other?).

4a) Which paths are available for users to code in C to a simple terminal or nRF UART 2.0, versus which match to a Tool?

4a1) I expect these to be user friendly and bidirectional: [uart_SeggerVirtualCom to Terminal] and [ble_uart to the UART2.0 App].

4a2) Some are reserved for Keil/nRFgoStudio/MCP/nRFTools/Apps

4a3) Maybe some can be enabled for display in Keil/nRFgoStudio/MCP/nRFTools/Apps?

4b) Some I found in various examples:

4b1) ble_app_hrs: main.c: app_error_handler()

4b2) ble_app_hrs: app_trace.h: ENABLE_DEBUG_LOG_SUPPORT

4b3) I see mention of "nrf assert", "debug assert", and "softdevice assert" but am unclear how to use or what tool they each work with (Keil/nRFgoStudio/other/..), or maybe you have to code to light a LED or set a GPIO, and code to put data in a memory block for examination, or dump by simple uart?

  1. Which examples should have working debug (uart or other)? It seems only partly implented in some examples.

5a) OK: \nrf51_sdk_v6_1_0_b2ec2e6\nrf51822\Board\pca10001\uart_example (sdk610, erase s110)

In the Default build I see on PuTTY or TeraTerm the "Start:" and get good echo of typing from simple_uart_get() and simple_uart_get().

5b) Incomplete: \nrf51_sdk_v6_1_0_b2ec2e6\nrf51822\Board\pca10001\s110\ble_app_hrs (load s110)

5b1) This example seems to have partly coded debug on uart(SeggerVirtualCom)? When I enable ENABLE_DEBUG_LOG_SUPPORT I don't see any output

from uart. When I comment out (//#define DM_DISABLE_LOGS) I get a compile error.

5b2) Only enabling ENABLE_DEBUG_LOG_SUPPORT, putting app_trace_init() at beginning of main(), and putting an app_trace_log("+") in the main loop I can see two cycles for each HRM BLE update when App connected [nRF Toolbox - HRM].

5c) Unclear: \nrf51_sdk_v6_0_0_43681\nrf51822\Board\pca10001\s110\experimental\ble_app_uart (sdk600, load s110v71)

This appears to give output on ble_uart to the App [nRF UART 2.0] and App [nRF Toolbox - UART], but I'm not sure its processing any typing input from App.

  1. I tried these Terminal Packages: (I tested with: Win8-64bit, s110v7.1.0, and SDK6.1.0)
  • Using [nRF51822 UART P0.8~P0.11 == SeggerVirtualCom]

6a) PuTTY 0.63 works (see 5a and 5b2), connection-serial [Com*,38400bps, 8, 1, none, CTS-RTS], See: http://www.putty.org/ and

www.ehow.com/how_8733462_use-putty-serial-connection.html

6c) TeraTerm 4.8.4 works (5b2), Setup-Serial [38400, 8, none, 1, Hardware, 0, 0], en.sourceforge.jp/.../

6b) RealTerm 2.0.0.70 displays garbage (Fails 5b2), www.softpedia.com/.../RealTerm.shtml

  1. Are there any compatibility issues with the different types of debug and BLE or certain tools or Apps?

7a) i.e. If fast BLE then slow uart may delay BLE, or uart comms may be truncated by BLE actions?

7b) Which will work even with SoftDevice(s110v7.1.0)?

  1. Note: Describing debug types and usage might all be more appropriate in a Blog, with clear naming for each data path type to avoid confusion, such as: hw_segger_uart (terminal), hw_segger_swdio (keil?, nRFgoStudio?), hw_ble (MCP?, App?), dongle_ble_uart (??), dongle_ble_swdio (??), app_ble, app_uart, ...

  2. A list of which debug types shouldn't be used in final production code (i.e. only suitable for development and temporary testing), some of this is in example comments but that can be easily missed as code grows and passed to different developers (wishing for good code review practices).

  3. (Personally I like the DAC trace method I saw in a magazine article: If you have a true DAC (not PWM) then at any point in code program a level and you can watch on a scope the code running and see normal patterns and unusual events in real time, no comms slowdown).

===========

Related