Hardlock Issue (no GPIOTE)

[Gerry Ortoli]

I'm completely out of ideas.

I've been developing a server for some time now based loosely on the ble_app_hrs sample using the 5.2.1 SD. Things have been going reasonably well. Things began to get weird when I attempted to add my own IRQ handlers & found multiple examples of how to do this, based on whether one is or is not using the SD. FWIW, I've not yet discovered a good guide to these very different approaches. Whatever, I did receive some guidance here & my interrupt seemed to be working.

Today I removed all of that for other reasons. I also removed all references to simulated sensors.

All I have left are the app timers exactly like the ble_app_hrs sample. Now suddenly I'm getting a hardlock on sd_ble_gatts_value_set() within ble_bas_battery_level_update().

Obviously I've compared my current & previous source files. I don't see anything weird. I've read the other question about the hardlock related to sd_ble_gatts_value_set(). I do have app_gpiote.c included but don't see how that could be a factor.

Any suggestions?

[Ole Morten]

Could it be that the problem you're seeing is this?

[Gerry Ortoli]

Thank you for responding. Sorry if I wasn't clear in my original description but I've removed all of my IRQ changes & still have the problem. The code that's left does not (intentionally) do anything with GPIOTE. I had been thinking of ways to leverage PPI but fortunately have done nothing with it, ever.

I can breakpoint on the entry to app_error_handler(). The call stack indicates arrival from battery_level_update(). This portion of the code is unchanged from ble_app_hrs sample.

For lack of any better idea, I removed the application timer that periodically calls battery_level_update(). What I did was remove the definition of the associated app timer (from timers_init) as well as the timer start (from application_timers_start). I did a clean and rebuild all. Interestingly, the call stack continues to show the battery_level_update preceding the app_error_handler break. (huh?!)

I used the nRFgo Studio to erase the chip, then replaced the SD, finally replaced the application with a known-good binary from November. The device briefly shows up on BTLE, then hangs. Lastly, I made certain the SD image I'm using is identical to the original download (it is).

If I can trust the nRFgo Studio full chip erase, then at this point I must consider a hardware failure. Any ideas what could have happened to cause this situation? I only have 1 other prototype & am hesitant to risk it until I know more.

Thanks again in advance!

[Ole Morten]

Which toolchain and IDE do you use? Can you please supply me the complete project you're working with? It sounds as if this case may be easier to handle as a regular support case, since it isn't as much a single question/answer, so I suggest that you create such case, uploading your complete project, so that I can test it here.