So you have gotten to the point where your application is running, and your device boots. However, there is something that is not working. It could be errors over UART or I2C/SPI, or maybe the custom board or test setup is not performing as you would suspect, you’re just not hitting the envisioned performance.
How to move forward in the debugging process depends entirely on the situation. Poor RF performance will require a different approach than noisy UART lines. So there is no single tool to fix it all.
However, in general, you will come far with the following tools:
If your code is building and you flash your application to your device and something is not working, the first steps are usually something like this:
1. Is the device powered with the correct voltage?
2. Is the correct COM port selected?
3. If there are any wires, are they properly connected?
Using LEDs to debug is an easy option to verify that a function or a part of the code is reached while running the application. This can also be done by setting the pin level and measuring it with a PPK, multimeter, or DLA. Sometimes you may not have the option to use a print interface, and then a LED or pin level can provide helpful information regarding where you are in the code.
static void start_scan(void)
{
struct bt_le_scan_param scan_param = {
.type = BT_HCI_LE_SCAN_PASSIVE,
.options = BT_LE_SCAN_OPT_NONE,
.interval = SCAN_INTERVAL,
.window = SCAN_WINDOW,
};
int err;
err = bt_le_scan_start(&scan_param,NULL);
if (err) {
gpio_pin_toggle_dt(&led); //toggles the led if the fuction fails
return;
}
LOG_INF("Scanning successfully started");
}
CThe PPK is able to read up to eight digital input channels at the same time and may, in some cases, be easier to use than LED’s. This means that is it possible to use the PPK as a simple low-end logical analyzer. This can be achieved by connecting the digital inputs to an I/O pin on the external device under test (DUT). In order to use this functionality, the DUT must be powered by a VCC voltage of 1.6-5.5V. The digital input can then show what code is executed in the DUT at different points in time.
Logic port
The device’s current consumption can be a good indicator that something is wrong. If the current draw is far from the expected result, that is a good reason to investigate. A Power Profiler Kit (PPK) or a similar device is useful at this stage.
However, it is important to remember that the device can not enter sleep mode while the debugger is attached to the computer over USB and the debugger is attached logically (meaning no debug session is started). This means that in order to properly measure the current draw, the device needs to be powered over the External Supply pins and not USB as seen in the documentation. The USB interface may also induce noise in the measurement.
Is the correct crystal set? If using a custom board without external LFCLK , you would need to activate the Low Frequency Clock (LFCLK) with Kconfig flags as the DK uses external LFCLK that is enabled by default.
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y #this will not be valid for all devices
Kconfig