Nov 18, 2020
02:36 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 18, 2020
02:36 AM
Hello all,
I can't clear ALM 2[7] (PFLASH ECC monitor).
It's failing inside the PmuEccEdcTst.c (Aurix SafeTlib). One of the test steps attempts to clear all SMU alarms and this is failing fails because AL2[7] is still set.
I've enabled CBAB & UBAB monitoring with the debugger and executed the alarm clear code. There are no valid entries but AML 2[7] is still set after the clearing of the alarms.
Does anyone know how I can I work out why the alarm is continually active?
Regards,
Mark.
I can't clear ALM 2[7] (PFLASH ECC monitor).
It's failing inside the PmuEccEdcTst.c (Aurix SafeTlib). One of the test steps attempts to clear all SMU alarms and this is failing fails because AL2[7] is still set.
I've enabled CBAB & UBAB monitoring with the debugger and executed the alarm clear code. There are no valid entries but AML 2[7] is still set after the clearing of the alarms.
Does anyone know how I can I work out why the alarm is continually active?
Regards,
Mark.
4 Replies
Nov 18, 2020
04:57 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 18, 2020
04:57 AM
Has the PFlash been initialised at all? If not the ECC will mismatch, and this could explain the error being set. You can also read the ECCS registers for the PFlashes to see what type of ECC error they are reporting.
Nov 19, 2020
12:18 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 19, 2020
12:18 AM
Make sure that there is no access to any erased pflash location e.g. there is a window to pflash open in the debugger which is not programmed.
Nov 19, 2020
12:39 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 19, 2020
12:39 AM
I resolved the issue after 5 hours of debugging with the client.
There were no CBAB or UBAB entries, no other PFLASH related alarms, only one core was active, the debugger was not accessing the PFLASH (used a hot attach) and the PFLASH was fully programmed.
It turns out that there was a bug in their Bootloader. It was turning off the ECC protection to scan and check application validity and a bug resulted in the ECC correction being left disabled.
It appears that ALM 2[7] is permanently active if the ECC Correction is disabled, but I cannot find any reference to this effect in the User Manual.
There were no CBAB or UBAB entries, no other PFLASH related alarms, only one core was active, the debugger was not accessing the PFLASH (used a hot attach) and the PFLASH was fully programmed.
It turns out that there was a bug in their Bootloader. It was turning off the ECC protection to scan and check application validity and a bug resulted in the ECC correction being left disabled.
It appears that ALM 2[7] is permanently active if the ECC Correction is disabled, but I cannot find any reference to this effect in the User Manual.
Nov 19, 2020
07:42 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 19, 2020
07:42 AM
AML2[7] is set in case of ECC monitor error. Set of this bit is not so easy but 1 part of it is disable ECC correction. Please see UM V2.1 chapter 11.8.7.3 Testing the SMU Alarm of the “ECC Monitor” how ALM2[7] can be set. Maybe there is an alarm test in the bootloader which is not correctly finished.