Code execution is trapped in DefaultHandler

[matthiasbock]

For some reason the code execution is currently stuck in continuous invokation of the default interrupt handler before the main code is even reached.

Default_Handler () at nrf51_startup.c:168
168     {
(gdb) s
175         uint32_t ICSR = *((uint32_t volatile *)0xE000ED04);
(gdb) 
176         uint32_t VECTACTIVE  = ICSR & 0x0000003f;
(gdb) 
177         uint32_t VECTPENDING = ICSR & 0x0003f000;
(gdb) 
178     }
(gdb) 
Default_Handler () at nrf51_startup.c:168
168     {
(gdb) 
175         uint32_t ICSR = *((uint32_t volatile *)0xE000ED04);
(gdb) 
176         uint32_t VECTACTIVE  = ICSR & 0x0000003f;
(gdb) 
177         uint32_t VECTPENDING = ICSR & 0x0003f000;
(gdb) 
s178    }
(gdb) 
sDefault_Handler () at nrf51_startup.c:168
168     {
(gdb) bt f
#0  Default_Handler () at nrf51_startup.c:168
        ICSR = 3
        VECTACTIVE = 3
        VECTPENDING = 0
#1  
No symbol table info available.
#2  0x000000fa in Reset_Handler () at nrf51_startup.c:156
        src = 0x5b8 '\377' ...
        dst = 0x20000004  "\002I\002\"\bh\020B\374\320pG"

[matthiasbock]

Confirmed that the problem did not exist in commit 8a773c50d7e57d9f0022c82894132fb9f9499703.

[matthiasbock]

Why does my Cortex-M processor Lock Up with a Hard Fault a few cycles after reset?

[matthiasbock]

Apparently using the type "uint8_t" is what caused the problem. Using "uint32_t" resolves the issue.