• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 383 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.

TMS320F280037C: Flash API fails when trying to write KEY and REV after a firmware update.

Jonas Vigdal
Prodigy 50 points
Part Number: TMS320F280037C

Hi, 

I have a project where I'm downloading data and updating the firmware over CAN. I'm using the flash API for the entire flash process. CRC is checked at the end of the download before KEY(0x5A5A5A5A) and REV is written. CRC test is passed, but then it fails at writing KEY and REV. I looked through the registers and noticed that the INVDAT bit is set.

Also:

  • If the application is running from bank 0 it works without a problem, but when in bank 1 it fails.
  • I have two different protocols implemented that can perform the LFU, both is based on CAN. They work differently in how they handle ID's and sequence numbers(It's like this to support two different download tools). Both of the protocols call the same function to write the KEY and REV. But it only fails when using one of the protocols, not both. 
  • The address where I try to write to is 0xFFFF.

Thanks for any tips.

Jonas

  • +1
    TI__Guru* 87145 points

    Hi Jonas,

    INVDAT indicates that you are trying to make a 0 -> 1 transition via program command.  This is not possible.  A 0 -> 1 transition needs erase command.

    Please check if you are trying to program an already programmed location - I see that you mentioned that is 0xFFFF.  However, you may have already programmed ECC for that location while programming other bits in that 64-bit segment (aligned).

    Thanks and regards,

    Vamsi

  • 0 in reply to Vamsi Gudivada
    Prodigy 50 points

    Hi Vamsi,

    Alright, so the protocols are made so that if they receive data that is 0xFFFF they does not write to flash. After reading this I double checked and noticed a small mistake in one of the protocols. It did in fact write 0xFFFF to flash and therefore the ECC was programmed to that location.

    Thanks for your help!

  • 0 in reply to Jonas Vigdal
    TI__Guru* 87145 points

    Hi Jonas,

    When you program any of the bits in a given 64-bit aligned memory section using Fapi_AutoEccGeneration mode, ECC will get programmed for the entire 64-bit segment since a 8-bit ECC is calculated for every 64-bits (aligned).

    Thanks and regards,
    Vamsi