The specific problem is as follows: the software is stuck in the SRAM area, which appears to be because HSE has started Recovery mode, causing the software to remain in WFI state.
Currently, the customer workflow is roughly boot_1-boot_2-app, with two levels of jumps. boot_1 is not updated. If the customer updates boot_2 separately in area A, there are no issues with subsequent A/B swaps and reset debugging.
However, it was found that when updating the APP separately in area A , the AB swap jump would occasionally fail , but communication would be normal after a reset .
The client has been investigating the following progress over the past two days (there are many screenshots, please check the following emails).
1. The error is still 0X2040012e. I checked the corresponding variable DCMROD3/DCMROD4 but found no ECC error.
2. After checking the progress with the customer, we now suspect that the device has entered recovery mode.
Hi @scott071209
First of all, here are possible reasons for recovery mode from S32K3 reference manual:
And here from HSE FW reference manual:
Do you use secure boot?
Is there the same boot_1 in both partitions? Is there valid IVT in both partitions?
Are there more than 8 resets? Did you check the reset signal by an oscilloscope?
Could you please provide more details about this sentence?
“However, it has been observed that when updating the app separately in area A, the AB swap transition occasionally fails, although communication is normal after a reset.”
How does it fail exactly?
Regards,
Lukas