• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 81 subscribers
  • Views 1633 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.

tms320f28023: When Flash_Erase() interrupted, settings stored in flash become all ZEROS. Why?

SusSousa
Prodigy 40 points
Part Number: TMS320F28023

Hi,

First of all, I know interrupting Flash_Erase() function could end up in something bad. I'm just trying to understand in detail what is happening in my particular situation. In summary, all registers in flash return a value of zero when flash erase is interrupted, which would make one think it could be related to CSM Password's corruption. Since, why all zeros? Why not corrupted random values? But there is an aspect of the behavior of the system that doesn't match with this explanation. Here are the details:

During a Flash_Erase, system is powered down. When reset, all stored settings used in firmware return a value of zero. Also, the variables calculated with the IQ functions of the IQmath library return zeros. So there is definitely something going wrong during the Boot loader, which is run in Boot ROM.

The strange thing comes here, once we jump to flash, to the main_app in sectors B and C, and try to write in flash, the process is successfully carried out. How would this be possible if the CSM password is corrupted? First thought is that the writing is done from INSIDE secure memory. However, the reading of the stored settings in sector D, is also done from the main app!!! So, why does the writing work but not the reading?

So, what is going on in here?

Flash_Erase corrupted - When reset registers return a value of zero - Writing enabled.

Thank you in advance!

  • 0
    TI__Guru 55700 points

    SusSousa,

    Why you read all zeros when device is CSM protected?
    On a CSM protected device, you can't access the contents of flash without unlocking the device.
    When the device is locked, CSM blocks the JTAG reads and shows 0x0000s instead. That is the way it has been designed.

    Why are you able to write in flash when you boot to flash?
    On CSM protected device, you can execute flash API algorithm successfully from secure RAM but not from unsecure memory. I believe your application code has flash API library build in and executes from secure RAM.

    Regards.
    <Manoj

  • 0 in reply to Manoj Santha Mohan
    Prodigy 40 points
    Hi Manoj,
    Thanks a lot for your reply! But I'm afraid I might not have explained well myself.

    I know that if CSM password is incorrectly unlocked, then we will get zeros when trying to read flash secured memory. And this is what I thought it was happening to my system. However, I realized writing was still working and I assumed it was still working because I am doing it from inside secured memory. So even if password would be corrupted, I could still write from inside secure memory. After this, I realized I was also reading registers from secured memory! So, how come I couldn't read registers from secured memory (getting zeros) but I could eventually write new values on them?

    2 possibilities here: a) there is a flash erasing carried out after the reading and before the writting (which I haven't found, so it's not very probable), b) there is a different explanation for the zero values not related to CSM.

    I found out, that Flash_Erase() has 4 stages: 1)pre-compact 2)Clear(setting all addresses to zero 3)Erase(setting all bits to one) 4) Compact.
    So could I just be interrupting Flash_Erase() in its clearing state? And this is why I'm getting all zeros?

    Thanks again,
  • 0 in reply to SusSousa
    TI__Guru 55700 points

    I'm not sure whether you are reading the flash in secure (or) unsecure state.

    • Can you confirm the contents of 0x3F7FF8 - 0x3F7FFFF?
    • What is the value of CSMSCR (address: 0xAEF)?
    • Are you trying to understand that why you see 0x0000s in certain sectors even when CSMSCR.bit0 = 0 (device in unsecure state)

    Regards,

    Manoj

  • 0 in reply to Manoj Santha Mohan
    Prodigy 40 points

    • Contents of  0x3F7FF8 - 0X3F7FFF: All FFs.
    • Value of CSMSCR : 0X0070
    • Yes. That is a good short explanation to what I'm trying to do.

      Some of our products have shown this behavior. All registers become zero, potentially due to a power cut during the Flash_Erase() function. At the beginning I thought CSM Password was getting corrupted, but not so sure anymore. As you see, they don't look corrupted when debugging the device with all registers already set to zero.

      So, what could another explanation be? Could these zeros come from the "clearing" stage of the erasing, instead?

      Many thanks again!

  • 0 in reply to SusSousa
    TI__Guru 55700 points
    When flash erase function is executed, flash api invokes the following algorithms sequentially:-

    • Flash compaction algorithm – This ensures that no flash bit cells are in over-erased condition (or) depleted state
    • Flash clear algorithm – This programs flash sector selected with 0x0000s to pre-condition the flash sector
    • Flash erase algorithm – This erases flash sector selected
    • Flash compaction algorithm – This ensures that no flash bit cells are in over-erased condition (or) depleted state

    As a part of Flash_Erase function, flash clear algorithm is also executed to pre-condition the flash. If the device is power cycled in the middle of flash clear algorithm you can possibly observe what you are seeing.

    Regards,
    Manoj
  • 0 in reply to Manoj Santha Mohan
    Prodigy 40 points
    Yes, I think that's what's happening. Thanks a lot for your help Manoj!
  • 0 in reply to SusSousa
    TI__Guru 55700 points
    Glad to help. I'm closing this ticket.