Jul 14, 2020
04:54 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 14, 2020
04:54 PM
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!
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!
- Tags:
- IFX
6 Replies
Jul 15, 2020
12:43 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 15, 2020
12:43 AM
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?
Jul 15, 2020
01:58 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 15, 2020
01:58 PM
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?
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?
Jul 16, 2020
03:09 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 16, 2020
03:09 AM
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.
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.
Jul 16, 2020
11:06 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 16, 2020
11:06 AM
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.
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.
Jul 16, 2020
03:23 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 16, 2020
03:23 PM
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)
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)
Jul 17, 2020
12:35 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 17, 2020
12:35 AM
🙂 Glad you found a solution which works.