Multilink - Causing Hardfaults

[c cook]

I'm running s120 v1.2 & SDK 9 My application will connect to, up to 8, known peripherals. If the connection is dropped or not established, my central app will try to continue to try to establish a connection. To the peripherals that do connect, my will start to write a small amount of data.

I use the call: sd_ble_gap_connect(), if this returns an error I call sd_ble_gap_connect_cancel(), and try to connect to the next peripheral. After trying to connect to all the peripherals, I cycle back and retry the devices that did not connect. I repeat this until all devices are connected. I try connecting to a new device every 100 ms.

To the devices that I have connected to, I write 1 byte (with no response) every 300 ms to 2 seconds, using sd_ble_gattc_write().

If I have a peripheral, that dosen't connect, I usually end up getting a Hardfault. Using the suggestions from this post. I think the fault is generated from SOFTDEVICE_EVT_IRQHandler().

If all devices connect the hardfault is very rare, but can still occur.

My question is, because both sd_ble_gattc_write() & sd_ble_gap_connect() are calls to the stack, can a new SOFTDEVICE_EVT_IRQ, occur while the handler is servicing a previous SOFTDEVICE_EVT_IRQ? If so, would this cause the ARM M0 in the nRF51 to hard fault?

Thanks.

[RK]

Why don't you stick to the original thread about this problem instead of creating a second one, especially as the previous one actually has lots of good details and analysis in it and was possibly heading towards a result. Hardfaults are hard, especially the occasional ones.

And the answer to this question is an emphatic no, as I was going to say in a reply to the previous one. In fact all the speculation about interrupts there is going in the wrong direction and is just guesswork. If the MCU is servicing an interrupt then even if that same interrupt, or any of the same or lower priority, is raised, it won't be taken until after the handler returns from the first one. And you also ask there if a higher priority interrupt occurred and how would you stop that, and the answer to that is it doesn't matter if it did and you can't stop it nor would you want to. That's the point of interrupt priorities and the ARM is perfectly capable of stacking the state of the lower priority ones to take the higher ones and return back to where it came from.

Now we've sorted out where the PC actually is on the exception stack I'll go look at the other thread again later and see if it makes any more sense now.