Call function reset in faststandby's wake-up function will cause the variables assigned in this function to not take effect.
These variables are all defined in standbyram.
It seems that function reset in the faststandby wake-up function will restore the standbyram to the state before entering standby.
But this will not happen if you jump through bl reset_handler。
What is the problem?
very interesting question.
After spending a long time, I finally found that you just need to add a delay to ensure that the command
has enough time to execute.
It's so strange. How could a simple assignment statement take so long? This results in longer wake-up times。
This delay is just what I used for testing, not the minimum delay time.
But this should be the cause of the problem
But why is there no such problem through jump "bl reset_handler" ? That is no delay time.
It's difficult for me to explain the difference, it's beyond my capabilities.
I tested this because after the standby wakes up, It will cause the WDI watchdog timeout problem using the fls driver to erase and program the dflash, but the function reset will not. Can you give feedback on this problem?
"I tested this because after the standby wakes up, It will cause the WDI watchdog timeout problem using the fls driver to erase and program the dflash, but the function reset will not. Can you give feedback on this problem?"
Is this a new problem?
Isn't it okay to close SWT before entering standby mode or before performing memory operations?
more difficult to understand
You can sort out your problem, provide a demo program that can reproduce the problem (non-MCAL demos are best), and then send it to me, and I will upgrade it to the internal forum.
I didn't init the standby ram when function reset, the var modified in the main function didn't lose
.
Could you please share the project so that i can reproduce your problem.