stack overflow and STACK GUARD

[Jim]

       I am using nrf52832 SDK14.2 development, now the system will generate some strange exceptions, I am worried about the stack overflow, is there any way to confirm whether the stack overflows, where does the stack overflow?
      In addition, I saw the STACK GUARD library. What is the role of this library? I only saw the initialization function, did not see the exception reminder and other processing functions, it can help me confirm whether the stack overflows and overflows?

[wpaul]

Tony Garland said:

Not exactly sure what aspect of single-stepping is suppressing the read memory fault, but that seems to be what made me think it wasn't working.

Hm, interesting. I'm not sure what to tell you about that. In my tests, I've set a breakpoint right on the instruction that would generate the fault, and then done a "stepi" with GDB, to advance just one instruction further, and in that case I can see the PC jump to the expected exception vector.

It may have to do with exactly what debugger setup you're using. In my case, my development environment is a Nordic nRF52840 DK board (rev 1.0.0) with OpenOCD and GDB, using a stock GCC toolchain. The production environment is a custom board with nRF52840 board using an Olimex ARM-USB-OCD-H debugger (since our board didn't have an on-board J-Link) but the other parts are the same. Either way, the MPU protection worked as expected for both reads and writes.

I was going to suggest that you check the other MPU regions. According to the ARM docs, if you have two or more MPU regions that overlap, the higher number one takes precedence. So if there's another region which only blocks writes, that one might override your custom one if it has a higher region number.

BTW, you should be able to compile the code from my repo using a standard arm-none-eabi GNU toolchain (just make sure it's in your path and type 'make') and it will boot up and run on an nRF52840 DK board, though not very well, since there will be no graphics or sound. I was going to suggest you try that just to compare against your own code, but it sounds like that's not necessary now.

-Bill

[Tony Garland]

Hi Bill,

Yes, I had used stepi as well at times (also using GDB) and it stepped right through the read from zero, fetching the vector value successfully.  One reason why I didn't suspect the debugger as an influence is that a different region with memory protection to detect impending stack overflow (Nordic's STACK GUARD) -- which I modified to trigger on both read and write--works as expected, even when stepping. Both reads and writes immediately memory fault.

I'm confident that there are no other memory regions.  My code is running early in the initialization process, immediately after nrf_mpu_init() which clears all memory regions. And immediately after setting up this particular memory region, I test it--before any other code could possibly intervene.

A bit later, after setting up both regions, the MPU regions read as follows:

00> MPU->RNR = 0, RASR = 0x00080013, RBAR = 0x00000000
00> MPU->RNR = 1, RASR = 0x1029000D, RBAR = 0x2003B201
00> MPU->RNR = 2, RASR = 0x00000000, RBAR = 0x00000002
00> MPU->RNR = 3, RASR = 0x00000000, RBAR = 0x00000003
00> MPU->RNR = 4, RASR = 0x00000000, RBAR = 0x00000004
00> MPU->RNR = 5, RASR = 0x00000000, RBAR = 0x00000005
00> MPU->RNR = 6, RASR = 0x00000000, RBAR = 0x00000006
00> MPU->RNR = 7, RASR = 0x00000000, RBAR = 0x00000007

Region 0 is the NULL pointer region and region 1 is the stack guard. The other regions are empty/disabled (the RBAR returns the region number on read--the values were set to zero on write by nrf_mpu_init()).

I'm using a Segger J-LINK debugger and the project is built using Segger Embedded Studio--which uses gcc under-the-hood.  The target is custom hardware developed by a client.

Again - thanks for your time and thoughts on this.  I've got a working system for the purposes of what I'm trying to accomplish, even if I don't understand why stepping through reads at 0 acts differently than steeping through reads in the stack guard region.