random resets after kernel start

Kernel
1

ammannlu wrote on Wednesday, April 25, 2018:

hi
im running freertos on a efm32gg device (MCU),
i have an osal wrapper in c++oo which means, that the thread object is a template class where you input your desired stack size (aligned to 4 bytes of course).

i have random target resets after i call the scheduler start api, my threads execute 1 or 2 times then the reset occures for some reason.
it used to be no problem.
i was wondering if something corrupts the stack ( i checked 10 times that the alignment is right ). in this case, with an c++oo approach, i can easily control memory usage and allocate everying statically. the only thing what im doing (and what i not like this much) is that this way, the stacks are placed randomly in RAM rather than all close by each other and away from any other ram usage… i have concerns that some other program might overshoot and corrupt one of my stacks and this may cause the reset?

is there a tool inside the kernel that i could use to check if external stack manipulation has been happening so i know my system is corrupted?

i was playing with the tought of having 4 bytes before each stack and after, written with a “magic word” where i check periodically if those still are in place, but this covers just start and end, not if some other ressource writes in between.

any advice on how to proceed is highly appreciated!

thank you

2

rtel wrote on Wednesday, April 25, 2018:

im running freertos on a efm32gg device (MCU),
i have an osal wrapper in c++oo which means, that the thread object is a
template class where you input your desired stack size (aligned to 4
bytes of course).

EFM32 actually requires 8 byte alignment, not 4, but if you are calling
xTaskCreate() or xTaskCreateStatic() inside the wrapper then it will
sort out the alignment for you.

i have random target resets after i called the scheduler start api, my
threads execute 1 or 2 times then the reset occures for some reason.
it used to be no problem.

So what changed between it not being a problem, and it being a problem?

is there a tool inside the kernel that i could use to check if external
stack manipulation has been happening so i know my system is corrupted?

Not easily. You can get a stack trace shown in Simplicity Studio, if
that is what you are using. If it were corrupt, it might show up there,
but you would have to catch it before it reset.

Sorry to ask the obvious - but are you sure you don’t have a watchdog
timer being started somewhere? Does the EFM32 capture the last reset
reason?

i was playing with the tought of having 4 bytes each before each stack
and after, written with a “magic word” where i check periodically if
those still are in place, but this covers just start and end, not if
some other ressource writes in between.

If you have configCHECK_FOR_STACK_OVERFLOW set to 2 then the end of the
stack being overwritten will get detected as a magic pattern is written
to the end of the stack when the task is created (just all 0xa5’s). If
you wanted a magic pattern at the front of the stack then you would have
to shift the start of the stack a little in vPortInitialiseStack(),
which is in port.c, fill the space with your magic patter.

3

ammannlu wrote on Thursday, April 26, 2018:

EFM32 actually requires 8 byte alignment, not 4, but if you are calling
xTaskCreate() or xTaskCreateStatic() inside the wrapper then it will
sort out the alignment for you.

thank you. i will check this out and correct it, thanks for the advice. did not know that
(PS: how come? why choose a 8 byte alignment on a 32bit system?)

So what changed between it not being a problem, and it being a problem?

at this state, i cannot say yet. i will have to investigate further but the problem is this takes time (which i dont have :slight_smile: ). basically a lot of middleware code was added but none of them should affect the kernel by any means. if so there would be a bug inside them (like i said, may be some program just doesnt know when to stop and overshoots,…)

Not easily. You can get a stack trace shown in Simplicity Studio, if
that is what you are using. If it were corrupt, it might show up there,
but you would have to catch it before it reset.

Ok, ill keep this in mind, im currently working with atollic 8,1.

Sorry to ask the obvious - but are you sure you don’t have a watchdog
timer being started somewhere? Does the EFM32 capture the last reset
reason?

no double checked that too, i initialize the hardware watchdog but do not start it (enable==false).
i do capture the reset register on startup, it changes from time to time but most often it says:
“RMU_RSTCAUSE_BODUNREGRST - Brown out detector, unregulated power”

If you have configCHECK_FOR_STACK_OVERFLOW set to 2 then the end of the
stack being overwritten will get detected as a magic pattern is written
to the end of the stack when the task is created (just all 0xa5’s). If
you wanted a magic pattern at the front of the stack then you would have
to shift the start of the stack a little in vPortInitialiseStack(),
which is in port.c, fill the space with your magic patter.

good to know, i was not aware of the option “2” in general, thanks. i just use 0 or 1 in my configuration. currently the check stack OF option is set to 1.

4

ammannlu wrote on Thursday, April 26, 2018:

EFM32 actually requires 8 byte alignment, not 4, but if you are calling
xTaskCreate() or xTaskCreateStatic() inside the wrapper then it will
sort out the alignment for you.

thank you. i will check this out and correct it, thanks for the advice. did not know that
(PS: how come? why choose a 8 byte alignment on a 32bit system?)

So what changed between it not being a problem, and it being a problem?

at this state, i cannot say yet. i will have to investigate further but the problem is this takes time (which i dont have :slight_smile: ). basically a lot of middleware code was added but none of them should affect the kernel by any means. if so there would be a bug inside them (like i said, may be some program just doesnt know when to stop and overshoots,…)

Not easily. You can get a stack trace shown in Simplicity Studio, if
that is what you are using. If it were corrupt, it might show up there,
but you would have to catch it before it reset.

Ok, ill keep this in mind, im currently working with atollic 8,1.

Sorry to ask the obvious - but are you sure you don’t have a watchdog
timer being started somewhere? Does the EFM32 capture the last reset
reason?

no double checked that too, i initialize the hardware watchdog but do not start it (enable==false).
i do capture the reset register on startup, it changes from time to time but most often it says:
“RMU_RSTCAUSE_BODUNREGRST - Brown out detector, unregulated power”

If you have configCHECK_FOR_STACK_OVERFLOW set to 2 then the end of the
stack being overwritten will get detected as a magic pattern is written
to the end of the stack when the task is created (just all 0xa5’s). If
you wanted a magic pattern at the front of the stack then you would have
to shift the start of the stack a little in vPortInitialiseStack(),
which is in port.c, fill the space with your magic patter.

good to know, i was not aware of the option “2” in general, thanks. i just use 0 or 1 in my configuration. currently the check stack OF option is set to 1.

5

richard_damon wrote on Thursday, April 26, 2018:

I have done some similar wrappers for FreeRTOS in C++, one thing to point out is that you shouldn’t create your tasks as local variables in main, as main’s stack is reused for the interrupt stack on Arm ports (don’t know if you are doing it, but is one thing I have learned from comments by others on using my wrappers).

6

richard_damon wrote on Thursday, April 26, 2018:

The 8 byte alignment restriction is an ARM API spec, there are a few instructions (double word load/stores) that need their address 8 byte aligned, and thus the stack needs to be 8 byte aligned to handle puting targets for these on the stack.