nRF51822 - Exception on Stack Overflow

RE: nRF51822 - Exception on Stack Overflow

los — Wed, 28 Jan 2015 17:47:22 GMT

Hi,

Nice topic. In order to detect stack overflow or stack usage more dynamically, stack can be regularly filled with a given pattern for example in application loop, then it can be checked in next loop iteration.

void MemoryWatcher::paintStackNow(void)
{
    uint32_t *p = (uint32_t *) GET_SP();

    while(p >= &__StackLimit)
    {
        *p = FREE_MEM_PATTERN;
        p--;
    }
}

github.com/.../memory_watcher

RE: nRF51822 - Exception on Stack Overflow

Joe Merten — Thu, 28 Aug 2014 09:31:14 GMT

I'd just tried it out but stuck (see Edit 2014-08-28 in my question). Could you help me to find the right value for NRF_MPU->RLENR0 and how to write it into?

RE: nRF51822 - Exception on Stack Overflow

Joe Merten — Thu, 28 Aug 2014 06:48:27 GMT

Very thanks for that information. I'll give it a try now.

May that approach charged by a software patent (see here)? I think no, because the patent text sounds more like the separating from softdevice and application.

RE: nRF51822 - Exception on Stack Overflow

Joe Merten — Thu, 28 Aug 2014 06:00:55 GMT

That's the way I currently also do it (and I also filling the heap with a different pattern). Actually, I'm far away from having stack usage problems. But If one occours, I think by producing a hardfault, there might be a way to identify a bit of callstack.

RE: nRF51822 - Exception on Stack Overflow

Nikita — Thu, 28 Aug 2014 05:39:46 GMT

I don't know how to do it with generating hardfault, but I just periodically check whether the stack overflowed or not and generate error if it is.

For this I fill stack with 0xDEADBEEF in startup file and periodically check maximum stack usage.

In reset handler:

Reset_Handler:
    .fnstart

/* Make sure ALL RAM banks are powered on */
    LDR     R0, =NRF_POWER_RAMON_ADDRESS
    LDR     R2, [R0]
    MOVS    R1, #NRF_POWER_RAMON_RAMxON_ONMODE_Msk
    ORRS    R2, R1
    STR     R2, [R0]

                 LDR     R0, =__StackTop
                 LDR     R1, =Stack_Size
                 LDR     R2, =0xDEADBEEF
.Fill:
                 SUBS    R0,#4
                 STR     R2, [R0]
                 SUBS    R1,#4
                 BNE     .Fill

Get maximum stack usage:

extern uint32_t __StackTop;
extern uint32_t __StackLimit;
uint32_t stack_overflow_debug(void)
{
    uint32_t stack_usage = 0;
    uint32_t offset = 0;
    uint32_t * value_addr = (uint32_t *) &__StackLimit;

    for (; offset <  ((uint32_t)&__StackTop - (uint32_t)&__StackLimit); offset=offset+4)
    {
        uint32_t new_val = *(value_addr + offset);
        if (new_val != 0xDEADBEEF )
        {
            break;
        }
    }
    stack_usage = ((uint32_t)&__StackTop - (uint32_t)&__StackLimit) - offset;

    return stack_usage;
}

RE: nRF51822 - Exception on Stack Overflow

RK — Thu, 28 Aug 2014 05:35:33 GMT

Softdevice doesn't touch them, CLENR0 is written as part of the softdevice upload procedure (or not even at all in recent softdevices) and I've never seen anything write RLENR0 ever. I'd stick it in the hex file upload and do it there.

This is partly why I haven't bothered.

RE: nRF51822 - Exception on Stack Overflow

Nikita — Thu, 28 Aug 2014 05:31:33 GMT

Is it possible to change RLENR0/CLENR0? Isn't softdevice changing this registers on start and block access to them (I can't found any softdevice call to change them and in S110_SoftDevice_Specification_v1.3A.pdf it's written that if softrevice is running access to MPU is restricted)?

RE: nRF51822 - Exception on Stack Overflow

RK — Thu, 28 Aug 2014 02:46:01 GMT

If you were feeling particularly clever you could try getting your linker map to organise your code so it looks like this ...

FLASH: [ Softdevice.. ][Your code ][ empty flash + pstorage ]

RAM: [ Softdevice RAM ][ Thread Stack ][ ... empty ...][ Process Stack ][Heap]

Then you set RLENR0 in the memory module to just before the Process Stack and make sure CLENR0 is set correctly too.

Malloc - assuming you find out why yours appears not to be working properly, will then fail if you over allocate heap and return 0 and I believe that any code running in region 1 (above CLENR0, i.e. your code) will fail if it tries to write into R0 RAM, that should include pushing too much on the stack and descending it below RLENR0. According to section 8.1.2 of the manual, that should cause a hard fault. ( don't know why nothing seems to generate MemManage faults on this chip but there you go).

That also nicely decouples your stack from the softdevice one.

I keep meaning to set CrosssWorks up to do this, it has all the symbols in the thumb_crt0.s file to set up the second stack pointer but just sort of can't quite be bothered.