• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 441 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RM48L952: CRC checking of uninitiated FLASH causes ESM faults

Allen Hayward
Prodigy 150 points
Part Number: RM48L952
Other Parts Discussed in Thread: HALCOGEN

Hello,

I am trying to use the CRC and DMA modules to do an error check of the FLASH memory content, specifically the program storage locations. I am using a Semi-CPU mode where I manually initiate the DMA block transfer of data from the FLASH memory to the CRC register. This works as expected until the DMA is allowed to check a FLASH address past the end of the programmed space. At that time, as expected, the DMA sets the imprecise error flag in the ESM due to it reading a FLASH value with an incorrect (uninitiated) ECC value. In some cases I also get a  FMC uncorrectable error in the ESM.

A simple solution would be to stop the DMA read just short of the programmed space or at exactly the end of the programmed space. This is a problem while developing the code as the end of the programed FLASH is always changing with each edit. Also trying to pick an element and frame count to match this exact address is an issue.

It seems the easy solution would be to simply fill the remainder of the flash bank with a default value which would also set the ECC values. So far I have not found a way to do this. 

I feel like I'm missing something very simple here. Examples are given showing the DMA and CRC being used automatically to check FLASH memory for errors, but there is no mention of this issue. Unless the DMA stops at the last programmed FLASH value, the above mentioned errors will occur. What am I missing?

Thanks,

   Allen

  • 0
    TI__Guru**** 196526 points
    Hello Allen,

    You can use linker to generate ECC using a new syntax in linker command file. The command file will specify a separate memory range for the ECC inside the device's memory map.

    processors.wiki.ti.com/.../Linker_Generated_ECC
  • 0 in reply to QJ Wang
    Prodigy 150 points
    QJ,

    Thanks, this generates the ECC for the unused FLASH memory preventing the ESM error.

    In order to make it work the sys_link.cmd file from HALCoGen had to be modifed to accept the linker generated ECC. The remaining problem is each time the HALCoGen generate code is run it redefines the MEMORY back to the default. The updated ECC generating MEMORY definitions can be added to the user code section, but the main memory definitions are not in the user code section.

    Here is part of the sys_link.com file:

    MEMORY
    {
    // VECTORS (X) : origin=0x00000000 length=0x00000020
    // FLASH0 (RX) : origin=0x00000020 length=0x0017FFE0
    // FLASH1 (RX) : origin=0x00180000 length=0x00180000
    // STACKS (RW) : origin=0x08000000 length=0x00001500
    // RAM (RW) : origin=0x08001500 length=0x0003eb00

    /* USER CODE BEGIN (2) */
    /* Flash Memory */
    /* Bank 0 (1.5MB) */
    VECTORS (X) : origin=0x00000000
    length=0x00000020
    fill=0xffffffff
    FLASH0 (RX) : origin=(end(VEC......

    I commented out the HALCoGen MEMORY definitions, but they get un-commented when HALCoGen regenerates. This causes an error in the linker due to "memory range has already been specified". Below is what HALCoGen does to the sys_link.cfg file after regeneration:

    MEMORY
    {
    VECTORS (X) : origin=0x00000000 length=0x00000020
    FLASH0 (RX) : origin=0x00000020 length=0x0017FFE0
    FLASH1 (RX) : origin=0x00180000 length=0x00180000
    STACKS (RW) : origin=0x08000000 length=0x00001500
    RAM (RW) : origin=0x08001500 length=0x0003eb00

    /* USER CODE BEGIN (2) */
    /* Flash Memory */
    /* Bank 0 (1.5MB) */
    VECTORS (X) : origin=0x00000000
    length=0x00000020
    fill=0xffffffff
    FLASH0 (RX) : origin=(end(VECT

    Is there a way to disable the HALCoGen generated MEMORY definitions?

    Thanks,
    Allen
  • 0 in reply to Allen Hayward
    Prodigy 150 points
    QJ,

    I was able to answer my own question on the HALCoGen issue. I've included my solution below for others that may be reading this question.

    To disable the HALCoGen generated MEMORY definitions, add "# if 0" at the bottom of the /* USER CODE BEGIN (1) */ section just above the memory map. Also add "# endif" at the top of the /* USER CODE BEGIN (2) */ section just below the memory map. That allows HALCOGen to adjust the MEMORY section, but the linker ignores it. Here is the code that worked for my issue:

    /* USER CODE BEGIN (1) */
    # if 0 //Added to disable the HALCoGen generated MEMORY section below
    /* USER CODE END */

    /*----------------------------------------------------------------------------*/
    /* Memory Map */

    MEMORY
    {
    VECTORS (X) : origin=0x00000000 length=0x00000020
    FLASH0 (RX) : origin=0x00000020 length=0x0017FFE0
    FLASH1 (RX) : origin=0x00180000 length=0x00180000
    STACKS (RW) : origin=0x08000000 length=0x00001500
    RAM (RW) : origin=0x08001500 length=0x0003eb00

    /* USER CODE BEGIN (2) */
    # endif //Added to disable the HALCoGen generated MEMORY section
    //The below MEMORY section is used in place of the HALCoGen generated Memory map by the linker
    MEMORY
    {
    /* Flash Memory */
    /* Bank 0 (1.5MB) */
    VECTORS (X) : origin=0x00000000
    length=0x00000020
    fill=0xffffffff
    FLASH0 (RX) : origin=(end(VECT.....

    Thanks for you help. I'm back up and running again.
    Allen