Writing image to Slot1 partition causes a hard-fault for firmware update

RE: Writing image to Slot1 partition causes a hard-fault for firmware update

Vidar Berg — Thu, 04 Aug 2022 07:21:48 GMT

I'm glad to hear that it works now, thanks for the update. If you encounter a similar problem in the future, I would suggest you try the Thread analyzer. It will periodically print the stack usage for all threads.

Config settings to enable thread analyzer:

CONFIG_THREAD_ANALYZER=y
CONFIG_THREAD_ANALYZER_AUTO=y
CONFIG_THREAD_ANALYZER_AUTO_INTERVAL=5
CONFIG_THREAD_NAME=y

RE: Writing image to Slot1 partition causes a hard-fault for firmware update

Ryjan — Wed, 03 Aug 2022 15:12:11 GMT

Ok, that is making sense to me. I do think that it's fixed now. I increased the same thread that I had before a little more, by about 40 bytes and the log message finally spit out a message about a stack overflow. I doubled the stack size and now the function call to "flash_img_buffered_write" long longer fails.

Since this was a project I was handed with no familiarity with Zephyr, but was tasked with getting some DFU running the main task (always_run, in this case) was not large enough to handle the receive buffer I made for the DFU data. So this makes sense, it was just difficult to find the cause since the thread was so undersized that it would not spit out a log message. It would skip the log message running Ozone or the RTT viewer just the same.

Thank you, Vidar!

RE: Writing image to Slot1 partition causes a hard-fault for firmware update

Vidar Berg — Wed, 03 Aug 2022 14:59:55 GMT

I suspect it's a stack overflow because the MSTKERR bit is set and that MMFAR contains a RAM address.

Don't you get a crash log at all? Is it also the same if you run the program without Ozone (looks like ozone is halting the cpu when the exception is raised which may prevent the crash log from being printed)?

RE: Writing image to Slot1 partition causes a hard-fault for firmware update

Ryjan — Wed, 03 Aug 2022 14:50:36 GMT

When you say that this looks more like a stack overflow, what do you see that makes you think that? Is is because of the RAM address? I had a stack overflow last week and the log message spit our some good information so I was able to fix the thread size. With this I see no data. I turned the suggested option on, but I saw no difference in the terminal output. Right now I'm reading through the link you included about MPU-assisted stack overflow protection.

RE: Writing image to Slot1 partition causes a hard-fault for firmware update

Vidar Berg — Wed, 03 Aug 2022 14:30:56 GMT

Thanks for confirming. This looks more a stack overflow (MPU-assisted stack overflow detection). Do you have logging enabled so you can get the crash log from error handler? With CONFIG_THREAD_NAME=y it should tell you in which thread the stack overflow occurred.

RE: Writing image to Slot1 partition causes a hard-fault for firmware update

Ryjan — Wed, 03 Aug 2022 13:49:13 GMT

First, I will confirm that I am not using mcumgr protocol for BLE. I was not aware of that system, so that will prove valuable for some future projects. This project, however needs to be compatible with our old system. It is using our own proprietary protocol to be legacy compatible with older products.

I checked the MMFAR register and it shows 0x20007538 as the stored value. That looks like a location in ram rather than a location in flash. It's not that same address as the one I see calculated in code for the write. In the steam structure in the flash_ctx structure I get the correct offset of 0x00044000, but that's not the same as the MMFAR register. I has assumed that the address in the MMFAR was the location of the instruction that was causing the crash.

I've included a screenshot of the crash in Ozone:

RE: Writing image to Slot1 partition causes a hard-fault for firmware update

Vidar Berg — Wed, 03 Aug 2022 11:19:37 GMT

Could you check the MMFAR address as well to see if it is indeed in the slot 1 memory range? Also, can you please confirm whether you are using the mcumgr protocol to transfer the image over BLE or not (i.e if you are using the same approach as covered in this tutorial Add DFU support to your applicationn)

RE: Writing image to Slot1 partition causes a hard-fault for firmware update

Ryjan — Tue, 02 Aug 2022 14:57:02 GMT

Ok, I spoke too soon. I had to also add CONFIG_MCUMGR=y since CONFIG_MCUMGR_CMD_IMG_MGMT=y requires it. After that the compile system seems happy. Before VSCode was just underlining it and saying it would be changed to "=n". I added

CONFIG_MCUMGR=y
CONFIG_MCUMGR_CMD_OS_MGMT=y
CONFIG_MCUMGR_CMD_IMG_MGMT=y

to the prj.conf and it compiles fine. I checked the build folder .config file and "CONFIG_MPU_ALLOW_FLASH_WRITE=y" still appears, but I still get the same MPU hard-fault.

RE: Writing image to Slot1 partition causes a hard-fault for firmware update

Vidar Berg — Tue, 02 Aug 2022 14:12:12 GMT

Could you please post your build log which shows the error when CONFIG_MCUMGR_CMD_IMG_MGMT is enabled? Also, are you doing DFU over a proprietary protocol since you have work directly with the mcumgr flash functions?

Thanks

RE: Writing image to Slot1 partition causes a hard-fault for firmware update

Ryjan — Tue, 02 Aug 2022 14:05:42 GMT

I checked and found "CONFIG_MPU_ALLOW_FLASH_WRITE=y" in the build config, but I then checked for "CONFIG_MCUMGR_CMD_IMG_MGMT " in my prj.config and found that I had commented it out. When I try to add it, VSCode claims that the in the build it's set to "n". It is very hard to trace and find out why, but I assume it is a Kconfig rule set somewhere else that is in conflict with another. Still "CONFIG_MPU_ALLOW_FLASH_WRITE" is set in the build file.

RE: Writing image to Slot1 partition causes a hard-fault for firmware update

Vidar Berg — Tue, 02 Aug 2022 13:18:57 GMT

Hello,

Please confirm if your build includes CONFIG_MPU_ALLOW_FLASH_WRITE=y (you can check this in the .config file located in <build folder>/zephyr/). If this is not enabled, then you will get a fault exception you like you described. Although, this setting should have been selected already if you have enabled the flash APIs through the CONFIG_MCUMGR_CMD_IMG_MGMT config setting.

Best regards,

Vidar