Hi all!
We've been time-stamping GPIO events using PPI in nRF52, and it works* !
...but when using the SoftDevice, it apparently clashes with the PPI about 30ms after the BLE connection, and sd_ppi_channel_enable_get() triggers a Hard Fault:
(gdb) bt
#0 HardFault_Handler () at /home/cedric/nRF5/SDK/components/toolchain/gcc/gcc_startup_nrf52.S:421
#1 <signal handler called>
#2 0x0001c830 in sd_ppi_channel_enable_get (p_channel_enable=p_channel_enable@entry=0x2000ff3c)
at /home/cedric/nRF5/SDK/components/softdevice/s132/headers/nrf_soc.h:603
#3 0x0001ca7c in PPIClass::resetChannels (this=0x2000218c <PPI>) at /tmp/build_618945/sketch/PPI.cpp:173sa
#4 0x0001d112 in armSyncPulse () at /tmp/build_618945/sketch/pulse.cpp:47
We set the PPI in interrupt context so we decreased its priority as suggested in this forum (we tried prioritiy 3 and also 5).
...but it doesn't seems to be sufficient ;\
=> Would anybody have any suggestion to debug this?
=> Could the Nordic radio protocol be the only simple solution?
Anyway, thanks to all of you who participate here, it helped a lot for this project (PPI timestamp accuracy + timer sync trick + feasibility question).
Cedric ;)
- - -
- - -
*Context:
This project is about 3d positioning with HTC Vive lighthouses, everything is documented here:
- - -
Details:
The development environment (with makefile, etc) is documented online with the rest of the firmware:
github.com/HiveTracker/firmware#install
- - -
More details:
If it can help, the armex gdb function gives more details about the registers when hardfaults happen:
(gdb) armex
EXEC_RETURN (LR):
lr 0xfffffff1 0xfffffff1
Uses MSP 0x2000ff18 return.
xPSR 0x0
ReturnAddress 0xa
LR (R14) 0x2000218c
R12 0xc8300001
R3 0xca7d0000
R2 0x0
R1 0x2e
R0 0x2000ff3c
Return instruction:
0xa: movs r0, r0
LR instruction:
0x2000218c <PPI>: lsrs r4, r0, #32
