This one is throwing me for a loop.
We just did a small build of 40 devices based around the nRF52832. 1 device out of those 40 is behaving very strangely. When the device is running with a debugger attached and running (in other words, actively debugging), everything is fine. The firmware runs as expected without any problems.
Here's a little background with regards to the firmware. It runs on a 1 second wakeup cycle. The device wakes up, reads some sensors, transmits some packets on the 2.4ghz radio, and goes back to sleep.
When the debugger is not active, the nRF52832 will make it through 1 complete cycle and go to sleep. On the second run through main, the firmware crashes and burns due to a bus fault. SCB->BFAR = 0x5B2B02CF, which is not a valid memory location on the nRF52832. So it makes sense the bus fault handler is getting fired. SCB->BFSR = 0x00008200, which means BFAR holds a valid fault address and the PC value stack points to the instruction that caused the fault. Instruction 0x00011D52, to be specific.
0x00011d4c ldr r0, [r0, #4]
0x00011d4e ldr r1, [r4, #16]
0x00011d50 ldr r3, [r0, #0]
0x00011d52 ldr r3, [r3, #8]
These are the register values that were stacked automatically before entering the bus fault handler.
R0 = 0x20003008
R1 = 0x0000000D
R2 = 0x0000EE81
R3 = 0x5B2B02D7
R12 = 0x00000000
LR = 0x00011677
SP = 0x00011D52
xPSR = 0x61000000
It looks like 0x5B2B02D7 is in RAM at address 0x20003004, so the instructions up to the bus fault executed correctly. Garbage must have found its way into 0x20003004.
But that doesn't explain why the code runs fine with an active debugger, and why it is just this one device that behaves this way.
