Announcements

Help us improve the Power & Sensing Selection Guide. Share feedback

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User19896
Level 1
Level 1
5 sign-ins Welcome! First question asked
Hello,

I'm developing a bootloader on an Aurix TC297. I'm aware of the two ECC types and how to switch between them. I also understand why traps get generated when reading erased flash while the Safety ECC is enabled.

There are many use cases where the bootloader might attempt to read erased flash, so I need a way to gracefully handle the ECC errors. Is there a recommended solution for this without disabling the Safety ECC? I can't imaging I'm the only one that has run into this problem.

Thanks!
0 Likes
6 Replies
Darren_Galpin
Employee
Employee
First solution authored First like received
If an ECC error is generated by the Flash, it records the fact in the xBAB registers which are accessible to the user. Your trap handler could read these to determine what the error is, and then act accordingly?
0 Likes
User19896
Level 1
Level 1
5 sign-ins Welcome! First question asked
What could the trap handler realistically do besides set some sort of flag? And how could I resume execution from the handler if the PC saved is the one that causes the error? PC+1?

Assuming the trap handler works the way I need, it still seems to imply that any code that reads Flash directly should check for ECC errors after every read.

How does this work if I want to use the CRC engine?
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
Then you were trying to execute code from a location where there is no code - that is a software programming error? The trap handler could take you to a known safe location.

If the ECC error was single bit then it would be corrected. If it was uncorrectable, then you would get a trap. So there is no need to check for ECC errors after every read because you should trap automatically unless you disabled them.
0 Likes
User19896
Level 1
Level 1
5 sign-ins Welcome! First question asked
In the trap handler, I can see the instruction that generated the trap. In the case of an ECC error for reading erased flash, it's not that the code itself (a Flash read) doesn't exist, it's that the result of the read was invalid.

As this is a bootloader, there are many cases where this might happen and I would want to continue execution after returning from the trap. To give some context, the bootloader not only validates application images before jumping
to them to begin execution, but also programs new application images.

Because programming could fail, Flash must be considered in an unknown state by the bootloader (erased, partially erased, etc.). And since validating the application image involves many reads to that unknown Flash data, the bootloader needs to be able to resume execution and prepare for another programming session.

Some examples of reads for validation purposes include examining some metadata contained withing the application image, or calculating a CRC over the entire image.

The problem I'm trying to solve is how to deal with those specific ECC errors due to reading erased Flash to allow the bootloader to resume execution gracefully.
0 Likes
User19896
Level 1
Level 1
5 sign-ins Welcome! First question asked
I found a solution by just disabling the trap that gets generated when the ECC error occurs. I can still check whether an error occurred after reading Flash. It's a bit cumbersome but it works.

1) Enable ECC error tracking for PFlash and configure to track uncorrectable errors (UBAB.CFG)
2) Disable the PFlash ECC trap (MARP.TRAPDIS = 1)
3) Read Flash
4) Enable the PFlash ECC trap (MARP.TRAPDIS = 0)
5) Check if an ECC error was recorded and compare the address (UBAB.STAT)
Darren_Galpin
Employee
Employee
First solution authored First like received
🙂 Glad you found a solution which works.
0 Likes