PPI + SoftDevice = HardFault?

[Cedric Honnet]

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:

hivetracker.github.io

- - -

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

[Håkon Alseth]

Hi Cedric,

 

One of the changes from nRF51 to nRF52 is the amount of interrupt priorities available (cortex m0 vs cortex m4).

Here's the interrupt priority levels of the SoftDevice stack:

http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s140.sds/dita/softdevices/s130/processor_avail_interrupt_latency/exception_mgmt_sd.html?cp=2_3_2_0_15_1

 

You have two options to work around this hardfault:

1. Change the interrupt priority of the timer ISR to 5 or less, since SVC is handled in interrupt priority 4.

2. Instead of using the sd_ppi-API, you can call the NRF_PPI structure directly. This is because the PPI is an "open peripheral", meaning that the application can access it directly. The softdevice uses the hard-coded PPI channels as shown here. 

 

Kind regards,

Håkon

[Cedric Honnet]

Hi Håkon!
Thanks a lot for your answer ;)
(sorry for the answer time, holidays made it longer than expected)

It looks like there was 2 problems:
- The priority was set to 3 already, but it was done after the softdevice was started and that was not good apparently!
- Once this was fixed, using the nrf_ppi_xxx() functions worked ;)

Thanks again for your help!