This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Crash, TWI hardware, Softdevice, or bug in my code ???

We are developing an app that communicates with a custom LCD display via IIC (TWI in Nordic terms) so it needs to send a lot of data on the IIC bus. We have developed an interrupt driven power aware TWI driver. Since this driver needs to call the softdevice to access PPI and set up IRQs for its timeout timer (TIMER1), its IRQs are low priority. Other parts of the app use RTC1 for other timing tasks as well as the ADC (3 channels) all interrupt driven. In any case, with the softdevice enabled and the BLE stack initialized, but nothing BLE happening, all works correctly. Our app has run and been tested running this way for 36 hours without a problem. When I enable nonconnectable advertising, repeating every 2 seconds indefinitely it will crash sometimes in as little as a minute, other times it may take 15 or 20 minutes for the crash to occur. The crash always kills the TWI periphial. Watching the SDA and SCL lines with a storage scope, I see it actually stop clocking part way through transmission of the the address byte some times. Other times there will be a short (less than a microsecond) glitch on both lines just after the crash happens. My timeout timer correctly detects failure of the bus, however it seems that nothing I can do will recover without a cold reset. Once the crash has occurred, if I put a breakpoint in the routine that detects the bus failure, any attempt to trace the code from that point forward makes no sense. It's as if the JTAG interface has gotten messed up by whatever happened. I can place breakpoints wherever I need and trace without problems before the crash occurs. We have tested with first an eval kit attached to a custom pcb with our display mounted with jumper cables and also with our custom PCB with all hardware in place. We have tested with S110 5.2.0, 5.2.1 and the 6.0.0.1 alpha stack. One more item, have tried 3 different JLinks, same results with all. I am wondering if possibly we are seeing something similar to the post titled Spurious S110 crash noted in the link here. Or, is this a hardware issue, hopefully resolved in the next rev silicon we are all waiting for.

  • You can not normally step on from a breakpoint, due to the limitations given here.

    As for your crashes and similar, you should first of all make sure that you comply with all requirements given in the SoftDevice Specification and the appendix of the nRF51 Reference Manual. These are mainly:

    1. Use sd_nvic_* APIs instead of NVIC_* when the softdevice is enabled. This will also ensure that you don't have any interrupts with illegal priority (the default priority level 0 or priority level 2).
    2. Don't ever call softdevice API functions from interrupts with priority 1.
    3. a) Make sure to not do any flash operations when the softdevice is in a connection or advertising, or b) Make sure to only do flash operations when you know the softdevice will not need the radio, i.e. by using the radio notification feature.

    If you still have trouble, I'd be very happy to take a look at your code. Could you either upload it here, or create a support case and attach it there?

  • We are compliant with all 3 steps listed above and always have been. I did run across a solution in nRF51822-PAN v2.0 item #56. Implementing the steps outlined in that document seems to have resolved the situation. It will take a couple more days of testing to know for sure, but looks good for the moment. I am on the road today, but left one running on the bench, will see how it does when I get back tomorrow.
    A little related confusion is in regards to the PAN's posted. I see both nRF51822-PAN v2.0 and nRF51822-PAN v2.0A posted. The dates in 2.0 are much newer than 2.0A so I have to assume it is the most current. In any case the naming is a bit confusing. As to stepping past a breakpoint, I had suspected that to be the case with this part, but was unsure, thanks for the pointer to that post.

Related