ble_app_uart_pca10040_s132 crashes at app_error_fault_handler with stack trace implying the ram errata [108] RAM: RAM content cannot be trusted upon waking up from System ON Idle or System OFF mode is happening after adding *(volatile uint32_t *)0x40000EE4

[RichardGM]

I am using an nRF520 PCA10040 dev board with a nRF52832 module and I am trying to get the ble_app_uart_pca10040_s132 FW to run using the SES segger tool set.  After about 1-10 minutes it crashes, and when its run from the debugger its stack trace ends at the app_error handlers void app_error_handler_bare(ret_code_t error_code) and then __WEAK void app_error_fault_handler(uint32_t id, uint32_t pc, uint32_t info).  When I look at the stack trace I see a NULL pointer or one that points to illegal memory which causes a memory fault.  I can see in the function that is calling the function that shows the illegal pointer value that the calling function has a valid location it is trying to pass to the function that gets the corrupted pointer that causes the fault.  I have only seen the issue with call stack traces that start from an interrupt service routine.  I have seen it happen in 3 different ISRs.  I attached one here and saw the UART receive data interrupt happen with the fault and one other case.  The ram errata [108] seems to match the symptom if the interrupts are happening in a way that it wakes up the arm processor.

[RichardGM]

I decided to re-download the https://www.nordicsemi.com/Software-and-tools/Software/nRF5-SDK/Download SDK source code and when I recompiled it, the issue went away. The new copy of the nrf.h file included a #define NRF52832_XXAA that would tend to activate errata workarounds.  The original code seemed to have a preprocessor macro $(DeviceName)=nRF52832_xxAA that I thought was telling the compiler to conditionally compile the work arounds, but may not have been used by the compiler.  The new copy of the UART project has the same preprocessor macro too. Using the clean newly downloaded copy did fix the problem.