RTT with FTDI board using OpenOCD

[ThisIsntTheWay]

This question is less about the p-parasite and more about OpenOCD.

As I lack access to a J-Link debugger to program the nRF SoC, I've had to resort to an FTDI-based programmer with OpenOCD.
However, I suspect that my b-parasite doesn't quite work right and wish to investigate the logs it generates.
(It never blinks the LED nor broadcasts any BLE packets and I think that it gets stuck at power_management_init())

Now I've been wondering how to make use of the RTT functionality with OpenOCD, because I can't seem to get that to work either.
As I understand, one has to setup RTT in OCD before being able to 'use' it.
(Syntax: rtt setup <address> <size> <id>)

Unfortunately, if I try to do that with the example values as provided in the OCD docs, I am met with this message:

> rtt setup 0x20000000 2048 "SEGGER RTT"
> rtt start
rtt: Searching for control block 'SEGGER RTT'
rtt: No control block found

Both NRF_LOG_ENABLED and NRF_LOG_BACKEND_RTT_ENABLED are set to 1 in sdk_config.h.

Perhaps I am using the wrong address or control block ID?
My knowledge about RTT is admittedly quite limited.

For reference, I am using a nrf52833.

[ThisIsntTheWay]

Well, I've managed to get it to work it seems.
The problem was that my CB search buffer was too low (2048 bytes).
By allowing up to 80000 bytes (arbitrary choice), OpenOCD was able to find the control block:
rtt setup 0x20000000 80000 "SEGGER RTT"

It appears that the SDK places the RTT control block randomly in the heap (unless specified otherwise).

I was then further able to expose a TCP server on port 9090 to finally see RTT messages on channel 0:
rtt server start 9090 0

So, all's well that ends well ;)

[rbaron]

Hey @ThisIsntTheWay. Thanks for sharing! I'm really interested in giving OpenOCD a go and I feel encouraged after reading your comments. Would you mind sharing how you flashed the softdevice & firmware as well?

Btw, did you manage to find the original issue with the board?

[ThisIsntTheWay]

Hey @rbaron, I was indeed able to fix my issues with the board!
After some good old debugging with print-statements, I was able to determine that the board locked up at prst_ble_init(), specifically when calling nrf_sdh_enable_request().

Thanks to some googling I found some hints to overwrite the following definitions in sdk_config.h:

#define NRF_SDH_CLOCK_LF_SRC 0
#define NRF_SDH_CLOCK_LF_RC_CTIV 16
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
#define NRF_SDH_CLOCK_LF_ACCURACY 1

This instructs the board to use the internal quartz.
Either this is a quirk of the nrf52833, or the external quartz that JLCPB soldered on the board has gone bad.
I have not investigated this further yet.

Interestingly enough, these definition values were already present in the code, but commented out.
I guess you (or other contributors) must have faced the same issue as me already 😉

As for OpenOCD, I don't know how familiar you are with this tool already.
Basically, you use OpenOCD in tandem with configuration files that tell OpenOCD how to interface with a target (in this case the nRF) using an adapter (in my case an FTDI board).

Anyhow, I was able to program the nRF with the following commands:

• To flash the soft device
  • .\openocd.exe -s .\scripts -f .\scripts\board\nordic_nrf52_ftx232.cfg -c "program .\\path\\to\\s140_nrf52_7.2.0_softdevice.hex verify; exit"
• To flash the actual binary
  • .\openocd.exe -s .\scripts -f .\scripts\board\nordic_nrf52_ftx232.cfg -c "program .\\path\\to\\nrf52833_xxaa.hex verify; reset; exit"

Of course I did these commands in succession, that is first the soft device and then the b-parasite binary.

To open an RTT session:
.\openocd.exe -s .\scripts -f .\scripts\board\nordic_nrf52_ftx232.cfg -c 'init; rtt setup 0x20000000 80000 \"SEGGER RTT\"; rtt start; rtt server start 9090 0'

Obviously the use of configuration script(s) (Parameter -f) depends on what adapter you use.
The config I've used combines both the Adafruit FT232h as interface and the nRF52 as the target.
Generally, all config files under /board combine both an adapter and a target.

The -s parameter tells OpenOCD the directory to search for config files.
This is important for config files that use find as a mechanism to locate other config files/scripts.

One other tidbit about OpenOCD is that it cannot be interacted with in the terminal it was started in.
Instead, it launches a TCP server on port 4444 for that purpose.

Thus, to use it interactively, you must connect to localhost:4444 using telnet.

I know this is kinda much information, but these are things I wish I knew when I started using OpenOCD.
Unfortunately it's not all too user friendly.

[rbaron]

Hi @ThisIsntTheWay. Thanks for the fantastic and thoughtful writeup! It's incredibly helpful to me and for sure for other contributors. I will make sure to link your answer on the wiki. Tks!

As for the original issue, both nRF52840 and nrF52833 have, in addition to the high frequency CPU clock (noted as HFCLK in the datasheet), a low frequency clock (LFCLK) that powers the real-time counter (RTC) to keep track of time using very little power.

The LFCLK can be sourced in different ways (enum'd by the NRF_SDH_CLOCK_LF_SRC value):

0. An internal RC oscillator circuit. This is a "crude" oscillator that needs periodic calibration since it drifts a lot in comparison with to sources. To calibrate it, the nRF has to wake up the HFCLK, which is power hungry
1. An external XTAL like the ones we have here. This is ideal for low power projects, and what we usually see in nRF52 boards
2. Directly derived from the HFCLK

I indeed experimented with the internal RC (the one that fixed your problem). While it works okay, I remember seeing spikes in current which I attributed to the periodic calibration. It's not the end of the world, but something to be aware of. We don't need precise sleep/wakeup timing, so it would also be interesting to see if we can optimize the RC source power consumption.

If you have access to an oscilloscope, you should be able to probe the terminals of the crystal and check if there's anything wrong with it.

[ThisIsntTheWay]

Hi @rbaron, no problem and thanks for your insightful feedback!

Yeah I figured that there was a reason for the external crystal.
I hope these current spikes aren't big enough as to considerably influence battery life.

I indeed have access to an oscilloscope, albeit a cheap USB one.
Later today I'll try to diagnose the XTAL with it and will report back, maybe I just got unlucky with my hardware.

[ThisIsntTheWay]

Alright, turns the XTAL does work and I just did a poor soldering job of the nRF module.
The solder only bounded to the pin(s) of the module, but not the pad.

Anyway, the board no longer locks up on nrf_sdh_enable_request() using NRF_SDH_CLOCK_LF_SRC 1.