2021-05-31 05:55 AM
Hi all,
We have been testing our 2 images configuration SBSFU firmware update with our NUCLEO-L476RG. We have encountered 2 scenario's during which the different steps taken by the bootloader was not entirely clear to us. We could use your help to clarify this.
So in both scenario's we started by normally flashing our firmware to the STM32. Nothing special.
Subsequently, in the first scenario, we do a hardware reset to do a YMODEM transfer to transfer new firmware to the STM. When this update is completed, we again do a hardware reset and transfer new firmware again over YMODEM, before the previous firmware was validated (this was intentional for testing this scenario). You can find the output log of this scenario in the attached file output-log-scenario-1.txt.
We have 2 questions about this scenario and its output:
In the second scenario, of which you can find the logs in output-log-scenario-2.txt, a similar process happens. The first FW update installs successfully, and starts running. However, the second FW update is executed before the first FW update was validated (again, this was intentional for this scenario) and fails during the YMODEM tranfer.
Here we have 3 questions:
/* 3- No active firmware candidate for execution ==> Local download */
if (m_ActiveSlotToExecute == 0U)
{
/* Control if all active slot are empty */
for (i = 0U; i < SFU_NB_MAX_ACTIVE_IMAGE; i++)
{
if (SlotStartAdd[SLOT_ACTIVE_1 + i] != 0U) /* Slot configured ? */
{
if (SFU_IMG_VerifyEmptyActiveSlot(SLOT_ACTIVE_1 + i) != SFU_SUCCESS)
{
/*
* We should never reach this code.
* Could come from an attack ==> as an example we invalidate current firmware.
*/
TRACE("\r\n\t Slot SLOT_ACTIVE_%d not empty : erasing ...", SLOT_ACTIVE_1 + i);
(void)SFU_IMG_InvalidateCurrentFirmware(SLOT_ACTIVE_1 + i); /* If this fails we continue anyhow */
}
}
}
It would be great if you could give us some insight in the process behind this. Of course, we also checked the code, but some of these details we could not figure out.
Thanks in advance!
ac_gd
2021-05-31 07:13 AM
Hello @ac_gd ,
I'll start with the first scenario.
From the context I assume you are testing configuration with ENABLE_IMAGE_STATE_HANDLING enable.
If you look at the UM2262, in Appendix J the flow is described and your understanding seems to match the description in the UM.
The error message you received is returned on several different pre-rollback check-up, but generally it means the header contents do not match. Which is expected, as it's not a backup.
Jarda
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2021-05-31 08:02 AM
I'll look in detail on the second scenario tomorrow. It's obviously a different branch and it probably related to the fact that the first image was still the actual one, never replaced. Please in the meantime confirm what I wrote earlier.
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2021-06-01 02:00 AM
Hi @JHOUD, thanks for your answer and for the reference to Appendix J. I did not know it existed.
I've attached the flow image, combined with poor drawing skills. So looking at my output log and the flow, I guess my scenario follows the red line. A couple of follow-up questions:
Thanks in advance,
ac_gd
2021-06-01 02:10 AM
Hi @JHOUD, thanks again for your help. How I see it:
2021-06-01 07:52 AM
Hi @ac_gd ,
yes, the red line shows the flow that I believe describes best your case.
The flow is high-level, it's easy to see that not all code branches are included, only those needed to understand the underlying principle. So in reality I'd say the error message is generated in between.
I think I know what's exactly happening, but I don't have time to test it today. Please hold.
For the header-slot relationship, I'm going to steer your attention to Appendix B describing the dual slot configuration. The header contains both "measurements" (length, integrity) and the life cycle information.
Rgds,
Jarda
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2021-06-04 02:35 AM
Hello @ac_gd ,
I failed to replicate the exact same situation that your logs describe, so I'm not completely sure.
But I see the code that erases the active slot is commented as that this case should actually never happen. It covers the case when NO FW is found in ACTIVE slot and yet the slot is not empty. So basically I'd say the SBSFU function SFU_IMG_DetectFW failed to recognise your App as valid FW. But I do not know why that happened.
I'll take another look if you can send over a zip file with your project.
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2021-06-14 12:34 AM
Hi @JHOUD , sorry for the delay.
Too bad that you can't replicate the scenario. In the meanwhile, we also investigated the second scenario in more detail. I will repeat and clarify what I have done do create this scenario 2 and elaborate on what we found out. A first remark is that I always work with the exact same FW, for the original flashing and also for updates. The process:
** It is strange the bootloader can rollback to the image in the DWL slot, because after the COM ERROR, we found out that the SFU_IMG_EraseDownloadedImg() function in SFU_BOOT_SM_DownloadNewUserFw() is called successfully (return code is SFU_SUCCESS). So this means it is actually rolling back to an empty image. Is it possible that the headers are not erased and this causes the bootloader to think that the contents of the DWL slot is also valid and just pursues the rollback (which seems to be a plain copy)?
What are your thoughts about this?
Due to company policy, I can't share our SBSFU project. However, in the coming week (or the week after) I will try to replicate the scenario on a dev board with clean slate SBSFU.
Thanks for the effort,
ac_gd
2021-06-16 12:24 PM
Hi @ac_gd ,
I attached log of my attempt to recreate the behavior you described. You see that after unsuccessful attempt to rollback the active slot is empty and the SBSFU asks for FW to be sent. Which is expected behavior. Maybe I misunderstood something, so please check the log.
Frankly I find it difficult to understand how the rollback to non-existing App image could appear to pass.
I'm genuinely interested in any demo you could possible share with me.
Thank you,
J.
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.