Frequently Asked Questions / Troubleshooting
Why does the node ID on the platform Tmote not match with the observer ID?
There are two possible reasons why this could happen:
- Binary patching failed for some reason, e.g. because the uploaded target image is not an elf file or the symbol
FLOCKLAB_NODE_IDdoes not exist in the binary.
- You are trying to read the node ID from the EEPROM on the Tmote. The ID stored in the EEPROM can be overwritten by the users and is therefore not reliable. If you still want to use this method, you need to do the mapping by yourself. You could first run a test to read the current IDs, do the mapping and then run another test to write the desired node IDs (e.g. Contiki provides a function to write the EEPROM).
Why do I not get any serial output on the platform nRF5?
First, make sure that the GPIO configuration in your code matches the FlockLab specifiction. If the GPIO mapping is correct, then you need to verify that your code is properly flashed to the target device by running a simple blinky test application (check the output of the GPIO tracing). This ensures that there was no issue with the binary file conversion / upload to the target. Also, most users forget to include a bootloader / MBR in their image files. Note that FlockLab programs the nRF5 via SWD and a mass erase is performed before your code is flashed. This means you either need to make sure your code starts at address 0x0 or include the bootloader that would normally (= when you flash the dongle via USB) jump to the application code.
Why are the data trace results empty?
There are several possible reasons why the data trace results could be empty:
- Clock speed mismatch: make sure that the frequency specified in the
cpuSpeedfield of the
<debugConf>matches the actual speed of the target CPU (master clock / SYSCLK).
- Invalid SWO pin config: ensure that the SWO pin is configured in SWO mode and isn't used otherwise in your target code.
- Clock configuration is taking too long: the MCU clock configuration in your target code must be performed as soon as possible after the power-on reset. Once initialized, the master clock (CPU clock) must not be changed for the duration of the test.
- Use of low-power mode: you cannot use deep sleep modes while using data trace since the high frequency clock must be running all the time.
Why are the GPIO tracing results empty?
Make sure you have selected the correct pins for tracing (see GPIO pin mappings) and ensure the pins are configured as outputs in your code. Also, keep in mind that the pin must keep its state for at least 200ns in order to see the state change (tracing service has a sampling rate of ~10MHz).
Why does GPIO tracing fail with the error
buffer overrun detected?
A buffer overrun can occur e.g. if one of the traced pins is in a floating state and toggles uncontrollably. This will fill up the tracing buffer within fractions of a second and cause a buffer overrun, whereafter the tracing service will be stopped on that observer. Solution: make sure all the traced pins are always in a defined state.
Note: by default, tracing only starts 1s after the test to avoid capturing many erratic toggles at MCU startup. If your program takes longer than that to fully initialize the MCU, you can extend this tracing offset in the XML config file.
Where can I buy the DPP2 LoRa communication board for debugging on the desk?
The DPP2 LoRa comboard that is used on FlockLab is a custom board and not available as an off-the-shelf component. Since the hardware design files are open-source, you can manufacture your own boards (Gerber files available upon request). However, this is very cost-intensive for small batch sizes. Therefore, it may be a more economical option to buy a NUCLEO-L476RG and SX1262MB2CAS shield instead. The hardware is obviously slightly different, which necessitates adjustments to clock, GPIO and peripheral configuration. Our LWB sample code has a separate branch (
nucleo-devkit) which is compatible with the mentioned nucleo board and SX1262 shield.