• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 29 subscribers
  • Views 1879 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Flash Memory Erase / Write Questions

Warren Woolsey
Intellectual 526 points

Hi All,

I have a question about the flash memory erase / write functionality with the TMS570LC43xx. For my application we are using a custom bootloader, which accepts binary machine instructions through one of the SCI ports and writes them to flash memory at a known starting address and then onward. The problem we are having is that the application doesn't behave the same when using our bootloader as opposed to simply flashing the TMS570LC43xx using an xdsv100. Mainly we see run time errors in calculations that are performed fine using the debug version.

My concerns arise from using the disassembly tool, I noticed that when a block erase is performed on a bank of flash memory the erase value is not 0xFFFFFFFF for all addresses erased as it should be. Please see the below screen shot.

My concern is that the flash memory banks are not being erased correctly, and that when I write my own application into flash, it is not written correctly. (At the moment we are using a checksum based on the packets transmitted)

What I would really like to have answered, is why when I erase a block of memory, it is not erased to 0xFFFFFFFF but instead this pattern shown in the screen shot above?

Thanks

-Warren

  • 0
    TI__Guru**** 159445 points
    Hi Warren,
    I have two few questions:
    1. What version of the F021 Flash API library did you use to reflash the firmware? Is it the latest one 02.01.01?
    2. In your bootloader are you trying to do some type of blank check after you erase the application section?

    I think I can explain the screenshot you show. The LC43xx uses the Cortex-R5F processor with built-in ECC checking on its level 2 bus interface which is called the AXI-M interface. One key attribute of the AXI-M ECC checking is that it is always enabled. When you erase the application section the flash is supposed to be all F's as you would expect. After erase, the flash will have both the data and the ECC sections becoming all F's. If you do a blank check, the CPU is going to read the flash and makes sure that the data is indeed all F's. The problem is that the corresponding ECC for the data is also F's. An all F's data and an all F's ECC can actually be a double-bit or multi-bit ECC errors to the ECC logic. The Cortex-R5F ECC is of type SECDED (Single Error Correction Double Error Detection). When it is a double or muti-bit ECC error the SECDED circuitry is unable to detect any failures correctly. It may think that is is a no error or one-bit error or double-bit error. Hence, it can try to correct any bit by mistake.

    In the latest 02.01.01 API blankcheck routine it is supposed to address this problem by doing some tricks. I want to know if you are using the latest version and if you are using the blankcheck to isolate your problem.
  • 0 in reply to Charles Tsai
    Intellectual 526 points

    Hi Charles,

    To answer your questions:

    1. We are using v2.01.01 fo the F021 Flash API library.

    2. No we are not doing some type of blank check for the bootloader at the moment.

    - Warren

  • 0 in reply to Warren Woolsey
    TI__Guru**** 159445 points
    Hi Warren,
    OK. Can you give more details as to what runtime error in calculation you are refering to when directly flashing the application using the debugger vs. flashing using the bootloader?
  • 0 in reply to Charles Tsai
    Intellectual 526 points

    Hi Charles,

    Sorry I took so long to reply, things have been busy over here. We found the source of the issue, it did not have anything to do with flash memory erase / writing. When using the non bootloader version of the software, we were compiling it in the 'Debug' configuration from CCS. When using the bootloader version of the software, we were compiling it in the 'Release' configuration from CCS.

    It turns out, in the 'Debug' configuration all compiler optimization was disabled. In the 'Release' configuration, compiler optimization was enabled. It seems that the compiler was optimizing out something that was necessary for our software to perform calculations correctly. Once we disabled compiler optimization for the 'Release' configuration our bootloader version of the software worked just fine. 

    So it seems there is either a bug with the compiler optimization scheme, or perhaps the optimizer was working correctly and our code was written in such a way that it cannot be used with the optimizer.

    - Warren

  • 0 in reply to Warren Woolsey
    TI__Guru**** 159445 points
    Hi Warren,
    Thanks for the update. Glad your problem is resolved.