it seems not to crash with revision 13d823f307, but there is clearly a
problem with the command line here.
Is the context switch trying to save registers in a place where the argv
are stored, because this is not a user task but a kernel thread?
I could not find where the SP of new tasks was i
Some more gdb stuff found that *something* is corrupting the contents of
argv, silently.
I have used an access watchpoint to catch accesses to argv
The first calls are related to the memset that clears the stack frame
when the task is created, and I see the correct values.
HOWEVER, at some p
Well it's not the stack, same crash with the stack doubled from 4096 to
8192, BFAR still contains the suspicious 3 from the argv array
nsh> ps
PID GROUP PRI POLICY TYPE NPX STATE EVENT SIGMASK
STACK CPU COMMAND
0 0 0 FIFO Kthread N-- Ready 004056
The stack is a good candidate, I see that I reported
stack_alloc_ptr = 0x38004328, stack_base_ptr = 0x38004368
but at the crash we have :
R2: 38003a1c
SP: 380038c0
I will try that tomorrow, thanks for the idea.
Sebastien
On 5/11/23 19:39, raiden00pl wrote:
Have you tried to increase the s
Have you tried to increase the stack size for NSH ? Stack overflow in NSH
can cause some really weird hard faults, not that easy to diagnose.
czw., 11 maj 2023 o 18:34 Sebastien Lorquet
napisał(a):
> Hello,
>
> I have a stm32h7 board, based on the stm32h743zi2 nucleo.
>
> I have activated the w
