• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 32 subscribers
  • Views 746 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.

Request: Information about usage of F035 Flash API

Atsushi Kimura
Prodigy 30 points

Hello.

I am using F035 Flash API for FEE(Flash EEPROM Emulation) on TMS470MF0660.

Although I executed all Flash API from Flash bank 0 to handle bank1 data,

I was aware that according to SPNU493E following API must be executed from RAM.

-Flash_Blank_B()

-setup_state_machine()

Furthermore, according to spnz185A using Flash_Blank_B() is affected following Errata. (We used old version Flash library)

SDOCM00104972: Flash_Blank_B() does not enter read margin mode properly

Now we are considering modifying our software so that it conforms to User Guide.

However, our prototype software was used in several years. And adverse behavior has never been seen through various tests including product endurance test.

I have to explain to concerned departments reason why our software should be changed.

Is it possible to provide detailed technical information about followings?

(1)

If Flash_Blank_B() is executed from flash(different bank from being operated), what adverse behavior may occur? And what condition dose it occur?

Reading past posts, I understood the read margin mode affect all flash banks so instruction codes itself are read in margin mode. I understood that’s not good and without proper usage TI cannot warrant Flash retention period described in datasheet.

When read mode is changed, it may causes CPU error? If so, is there possible it depends on production lot?

(2)

Errata(SDOCM00104972) says “Blank check may fail when the sector of flash was really blank. Sometimes this gives a data abort.”

If false fail or data abort happen, how does it happen?  Randomly or deterministic?

(3)

If setup_state_machine() is executed from flash(different bank from being operated), what adverse behavior may occur?

Regards,

 

  • 0
    TI__Guru**** 191906 points
    Hi Atsushi,

    I will forward your question to our SME for confirmation.

    1. Basically, when you turn on the read margin mode it will affect all the banks. Since you are running code out of the bank0, the bank0 is also subject to margin mode while the code is being fetched. It depends if you have the ECC enabled. If you have ECC enabled, you might be masking out problems with bank0 where if you have a bit cell that is not meeting the required margin but the ECC will correct it. If the ECC is not enabled and if the bank0 has margin issue, then the CPU could have executed on corrupted instructions read from the flash. You may have unpredicable behavior. The same issue can happen to bank1 too. However, I tend to think that you are just finding out read-margin issues with bank0 earlier while trying to do blank check for bank1. This may not be a bad thing to happen in my opinion. In any case, I will let our expert comment if he has more insights on this matter.

    2. Due to the errata the state machine may incorrectly read from a wrong address that is not part of the bank1. That wrong address can be an illegal address in the CPU's memory map in which case an abort will be taken. If it is not an illegal address, it could be an address that has data that is not all '1' (erased state) in which case the state machine will misinterpret the bank1 as not fully erased. I think the wrong address could be random.

    3. I think the behavior can be similar to #1.
  • 0 in reply to Charles Tsai
    TI__Guru 72500 points
    Hi Atsushi,
    You and Charles are correct about the blank check. The issue is that the code being executed to do the blank check would be read in "Read Margin 1" mode. In general, that flash should be good for the specified lifetime in Read Margin mode. The only downside is that you have given up the margin that is used to do early detection of a flash problem. If the flash in bank 0 does become marginal, you would likely generate an ECC single bit or uncorrectable error.

    The second issue is a little less clear. The problem was found on a device with an R4 processor running at 160MHz. We have not ever seen this issue created on any of the M3 devices. The root cause of the problem is that the API software was switching out of a mode that caused the first flash read of the blank check to happen while the address was still changing. Two things make that less likely to happen on the TMS470MF0660, the slower HCLK (80MHz instead of 160MHz) and the M3 does not pre-fetch like the R4.

    The third issue I am less clear of. I know you cannot run setup_state_machine() from the flash bank that you are setting up to program or erase. Also there was an issue similar to the second issue that was corrected in the latest version of setup_state_machine(). Let me do some more digging on this one tomorrow.
  • 0 in reply to Charles Tsai
    Prodigy 30 points

    Hello Charles,

    Thank you very much  for your helpful and prompt reply.

    Regards,

    Atsushi

  • 0 in reply to Bob Crosby
    Prodigy 30 points
    Hello Bob,

    Thank you very much.
    Your answer is really helpful.
    I look foward to your additional information about setup_state_machine() issue.

    Regards,
    Atsushi