• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 612 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.

TMS320F28027: FLASH REWRITE

ksma
Intellectual 290 points
Part Number: TMS320F28027
Other Parts Discussed in Thread: TPS3306

Hello.

As shown in the attached circuit diagram, there is a circuit configuration of TMS320F28027 and external WD (TPS3306).

When rewriting the program with JTAG, open the jumper and disable the external WD.

But sometimes I forget to open it and do it closed.

In this case, the reset will be applied during writing and the writing will fail.

Also, the CPU will not be able to connect to JTAG and will never be usable again.

Do I get the same result when using SCI_BOOT?

Is there any countermeasure with SW / HW that does not damage the CPU even if I make the above mistake?

Thanking you in advance.

  • 0
    TI__Guru* 81560 points

    Thanks for reaching out to the E2E forum.  As you mention interrupting the flash program or erase procedures can result in random values in the flash memory.  If these occur in the CSM password locations, it can result in the device being permanently locked as you mention.

    In terms of connecting to a locked device, you can use the Wait Boot mode, to ensure that code is not inside any secure memory.  This will allow you to connect.  However, the flash, user OTP, and L0 RAMs will not be readable by the emulator.

    In terms of prevention, if possible do not use flash sectors A and H(if your code size allows it).  Or keep these as static as possible so they don't need to be re-programmed each time.  Sector A contains the flash passwords and electrically is balanced with sector H.  If we can eliminate or minimize the time these are re-flashed then if a reset occurs per above, we can minimize the risk that the passwords will be written to an unknown/non-erased value.

    There are settings in CCS in the flash tools that you can also set to not force re-programmation of not new data, etc.  I've attached a picture below.  As a safeguard you could set this to load to RAM, or verify only.  That way when you go to flash/load CCS will throw an error and you can use that to remember to pull the jumper before allowing a flash program. 

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Intellectual 290 points
    Thank you for your reply. Please tell me a little more.
    >> However, the flash, user OTP, and L0 RAMs will not be readable by the emulator.
    What exactly do you mean? Does that mean you can connect but not repro?
    >> In terms of prevention, if possible do not use flash sectors A and H (if your code size allows it).
    As an example, is my understanding below correct?
    I think 28027 is sectors A to D. Should I not use A and D in this case?
    / * Allocate program areas: * /
    .cinit:> FLASHC PAGE = 0
    .pinit:> FLASHC, PAGE = 0
    .text:> FLASHC PAGE = 0
    >> I've attached a picture below.
    >> That way when you go to flash / load CCS will throw an error and you can use that to remember to pull the jumper before allowing a flash program.
    Please tell me how to do it. It seems that the photo is not attached, so please attach it.
    Thanking you in advance.

    このソーステキストの詳細

    翻訳についての詳細を確認するにはソーステキストが必要です
    フィードバックを送信

    サイドパネル

  • 0 in reply to ksma
    TI__Guru* 81560 points

    Thanks for the reply, you are correct on this device there are only 4 sectors, and my statement would apply to A and D.  If that does not leave enough room I would try to reserve A if possible.

    In terms of a device being locked with an unknown password, then those memories would not be readable or writable(programmable) in that state. 

    There is a potential workaround, that involves copying the flash API(in the ROM) into L0 RAM and erasing the device.  You would have to code this into your program that is in flash, but could be a safety net if this happens again.

    I'll try to attach the picture again, will see if it comes through.

    Best,
    Matthew

  • 0 in reply to MatthewPate
    Intellectual 290 points

    The photo has arrived. Thank you.

    I'm scared and can't actually try it, but if I set it as an attachment, Will it warn me if the jumper is closed?

    Or do I need to edit the code additionally, such as using the memcpy () function?

    If so, do you have sample code?

    Thanking you in advance.

  • 0 in reply to ksma
    TI__Guru* 81560 points

    It won't warn if the jumper is closed, but it also won't attempt to program the flash either.  This way once you see this error you can remember to check the jumper before you change the setting from Verify only back to erase/program/verify. 

    There's no need to try it with the jumper closed/risk, you can put the jumper open, set to Verify only, then try to load the program.  CCS should issue an error that it cannot write to the flash regions with this set.

    Best,

    Matthew