TI E2E Community
Hercules™ Safety Microcontrollers
Hercules™ Safety Microcontrollers Forum
Flash ECC SECDED Fault with DMA Access doesn't update FEDACSTATUS Register Bit 8
When there is ECC SECDED Error in Flash and accessed by CPU with ECC Check Logic enabled, I get FEDACSTATUS Bit 8 [B1_UNC_ERR Bit] as TRUE.
When accessed by DMA, I don't see FEDACSTATUS Bit 8 as SET.
I thought FEDACSTATUS Bit 8 will get updated whether accessed by CPU or DMA.
Please confirm how FEDACSTATUS Bit 8 get updated.
Is it supposed to be updated only when CPU accesses the Flash?
I am using TMS570LS3137 device.
I have received your inquiry and I am looking into it. I will get back to you with a reply shortly.
Thanks and Regards,
If this response answers your question, please indicate it by verifying the suggested answer when provided.
Can you describe in a bit more detail your test methodology for arriving at the results you mention? i.e., are you using a single test case to access the faulty memory or do you have 2 separate test cases that access the same fault location?
Also, if you could provide details of the fault location and type (address or data), that might be beneficial.
I have following scenario:
Boot Code is resident at 0x0 to 0xFFFF with ECC Programmed in the respective FLASH AREA only. Rest all FLASH AREA is ERASED state.
Boot Code Performs all the necessary initialization related to Cortex-R4 ECC Logic as well as Flash Wrapper FLEP [F021].
Bootloader uses DMA to read all the FLASH Area from 0x10000 to 0xBFFFF and writes to CRC Register to calculate the CRC Value of the FLash ARea beyond BOOT Area.
I expect that under the above mentioned condition, FEDACSTATUS Register should have some bit at least set because of ERASED state of those FLASH Blocks.
I don't see any bit set.
In case you have any test case which disproves my findings, please attach the whole project and I will run it here.
I am using TMS570LS3137 HDK.
We have gone back and identified a test case that was ran during our device validation that exercised this feature and there were no issues. i.e., a test case was executed that accessed Flash with a double bit ECC error using DMA and the associated error status bit in the FEDACSTATUS register was asserted as expected.
Some additional items to check would be to check to insure only the lower part of Flash where your boot code resides is programmed and that the out file created does not inadvertently fill unused space with some value or that ECC data is not actually calculated for the memory above your boot section.
Also, I think, based on your initial post that ECC is enabled correctly since you stated you get an ECC error when accessing this same area by means of the CPU. However, I would like to confirm that this test was actually performed and not assumed just to be certain. If this is the case then, most likely, the prior point about memory fill and ECC calculation is not likely either.
In the end, it might be beneficial if you could attach or send me your test case and I could analyze the issue a bit deeper. If you are OK with proceeding down this path, please let me know and I can send you my direct email information.
In the following link http://e2e.ti.com/support/microcontrollers/hercules/f/312/t/123150.aspx you will find
as given by Haixiao Weng.
Then he also corrected at the following link
Can you please provide a Test Case with all the files in the project for the FEDACDIS Test with DMA?
That will be easy for me to figure out the issue.
Let me know.
Below is a zip file containing a CCS5 project and test that demonstrates the setting of the appropriate flags in both the Flash wrapper and in the ESM when DMA is used to access unprogrammed flash and move the content to CRC in full auto CRC mode.
I believe the issue you might have had is that you must enable the ECC in two places. First in the R4 core via the writes to CP15 and second in the flash wrapper by setting EDACEN to 0xA (FEDACCTRL1 = 0x000A000A).
When ECC is enabled in the core but not in the wrapper, the error signals from the core to the wrapper are ignored and the error flags in the Flash Wrapper and ESM will not be set.
My apologies for the lengthy resolution time. Let me know if there are any additional questions.
1> Please replace your original CRC11_HDMAAllch.c file with the new attached file as given in this mail [without _org appended].
2> Also, add the new file dabort.asm as attached here to your Code Composer Project
Then if you rebuild your project and test it, you will see that DMA Read of FLASH is not generating FEDACSTATUS error.
Let me know if you can't find the problem I am mentioning.
I have not had the opportunity to compile and execute the modified code you provided; however, inspection of the code leads to an observation about its effectiveness after your changes.
I see that you added a direct read of the first unprogrammed location of Flash with no ECC data. This read will cause the uncorrectable error bit in the FEDCSTATUS register to be set as expected. When this happens, you check for the bit being set (FEDCSTATUS == 0x100). If set, you write this value back to the register clearing the flag. At issue with this process is you do not read the FUNC_ERR_ADD register so this register remains frozen until it is read by the CPU. While this register is frozen, no other uncorrectable errors will be captured. This means my test at the end of the test case will fail because FEDACSTATUS != 0x100 even though there are additional accesses to the unprogrammed flash area.
The correct sequence for clearing the error is to clear the ESM error,clear the error flasg in FEDACSTATUS register, then read the uncorrectable error address from the FUNC_ERR_ADD register.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.