Fix core1 startup #1286
Fix core1 startup #1286
Conversation
MabezDev
force-pushed
the
fix-core1-startup
branch
from
19c3401
to
3973b17
Compare
|
I can confirm its working for me. |
The original code tried to set the stack pointer and call the closure _in the same stack frame_. This isn't possible, so the actual stack being used was the 8K stack setup by ROM code. If this stack overflowed, it could corrupt the ROM function .bss and .data which is why I was seeing intermittent panic messages. I still don't understand all the failure cases, but I know that now we are using the correct stack properly.
MabezDev
force-pushed
the
fix-core1-startup
branch
from
5e51b80
to
84a6280
Compare
|
Thank you for sticking it out with this! I can take a peek in the morning. |
MabezDev
force-pushed
the
fix-core1-startup
branch
from
84a6280
to
7d93d2e
Compare
|
Shouldn't the same change be done for ESP32, too? |
Oops, I forgot they weren't sharing the code. I will do the same for the ESP32 tomorrow, thanks! |
|
Not really related to the PR but I really wonder what the initial SP is when core-1 gets out of reset. I guess it's hardwired in hardware (assuming the boot address is really the first instruction the core will execute) 🤔 |
Nevermind - found the information |
|
It seems like the curtain of mystery is being lifted on the ESP32 issue: #1085 (comment) |
MabezDev
force-pushed
the
fix-core1-startup
branch
from
e0e18e1
to
365dcc3
Compare
* Fix core1 startup The original code tried to set the stack pointer and call the closure _in the same stack frame_. This isn't possible, so the actual stack being used was the 8K stack setup by ROM code. If this stack overflowed, it could corrupt the ROM function .bss and .data which is why I was seeing intermittent panic messages. I still don't understand all the failure cases, but I know that now we are using the correct stack properly. * Improve multicore example * Change log * apply fix to esp32
The original code tried to set the stack pointer and call the closure in the same stack frame. This isn't possible, so the actual stack being used was the 8K stack setup by ROM code. If this stack overflowed, it could corrupt the ROM function .bss and .data which is why I was seeing intermittent panic messages. I still don't understand all the failure cases, but I know that now we are using the correct stack.