Updating from SDK15.3 to SDK16.0, now it gets stuck in random interrupt handlers

[Ryjan]

I'm working on an nRF52832 based IOT product using Segger Embedded Studio for ARM v4.50 on my Windows 10 machine. My project uses FreeRTOS. Looking at the release notes for SDK16 it doesn't look to hard to get it updated from SDK15.3. It didn't take me long to drop in the new SDK and get my code to compile. After setting the RAM to the right values the program runs, but gets stuck. By getting stuck I mean that it's not crashing or resetting but the logs end up not showing up because it stuck. So I can hit the pause button and check out the call stack and see it was running. The very top call on the stack is always some interrupt handler. And it sometimes is different handler. It looks to me like the application is doing some of the initializations at start up and an interrupt comes in that has no handle. I've gotten the QDEC_IRQHandler(), and I am not using the quadrature decoder in this project. It used to be that I would pause the process when I would see that it was stuck and it would stop on line 112 of ses_startup_nrf52.s:

  .thumb_func
  .weak   Dummy_Handler
Dummy_Handler:
  b     .

Now all I see is the top of the call stack is an IRQ handler and I don't think that I'm using those. Most of the time it is TIMER4_IRQHandler sometimes a few others (TIMER3 and TIMER0). I have seen the RADIO_IRQHandler, and it would make sense that I am using that. My guess has been that the interrupt vectors are not pointing to valid handlers. I've been comparing example projects that are working to this and found no differences. I've compared the vector tables in ses_startup_nrf52.s and found no differences. Even when rolling back to code that uses SDK15.3 I can't find any evidence of these vectors being wrong or different.

At this point I'm not sure where to look next or how to dive deeper and how to dig into these handlers that I don't think should be called.

[Ryjan]

That was the problem. I changed this code:

#define xPortSysTickHandler     RTC1_IRQHandler

In FreeRTOSConfig.h to:

 #define xPortSysTickHandler     RTC2_IRQHandler

I do not understand how this was leading to dummy interrupt being called, unless the mismatch somehow caused the interrupt handlers to be offset and wrong interrupt handlers were being called by this offset in the vector table.