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.

TMS320F28069: Software update via boot ROM

Part Number: TMS320F28069
Other Parts Discussed in Thread: C2000WARE

Dear TI support,

We have realized software update of TMS320F28069 MCU by using the boot ROM in our project. During the process of transferring the image converted into boot table towards the boot ROM, there is a delay after sending a boot table header and receiving a CRC back from the boot ROM. This delay seems by be varying for different samples (e.g. from 3.2 s to over 5 s).

Thus, I would kindly like to ask following questions:

  • What is performed by the boot ROM after receiving the boot table header?
  • What could be the reason of having different delays for different samples with same TMS320F28069 MCU mounted?

Another concern is regarding the memory erase done. Presumably, at some point the boot ROM triggers the flash memory erase as well before continuing with memory write.

  • Is my understanding correct that the memory is erased at some point by the boot ROM before writing the new content?
  • At which point in software update via the boot ROM does destination memory area get erased?
  • Is there any information about the time needed for memory erase (e.g. best case, typical and worst case)?

Looking forward to your feedback and many thanks for Your support in advance!

  • Hi  

    Let us look at your second set of questions first:

    >>Another concern is regarding the memory erase done. Presumably, at some point the boot ROM triggers the flash memory erase as well before continuing with >>memory write.

    - There is no flash memory erase done by the Boot ROM code.

    • Is my understanding correct that the memory is erased at some point by the boot ROM before writing the new content?
      • No,  the memory is not erased by the bootROM 
    • At which point in software update via the boot ROM does destination memory area get erased?
      • Same as above
    • Is there any information about the time needed for memory erase (e.g. best case, typical and worst case)?
      •  This data is available, if needed.  However, it likely does not apply in the context of the previous questions you asked.

    Since there seems to be some disconnect in how the boot ROM support works, please review the questions you asked before and let us know if they are still valid.

    If you think they are still valid, then please let us know what exactly is your project trying to accomplish.  Are you using the the bootROM source code provided as part of C2000Ware as an example to create a boot loader or a develop a software update mechanism for your 28069 target?

    Thanks,

    Krishna 

  • Hello,

    Thanks for your response and explanation.

    Our project consists of 2 MCUs uses and 28069 is a slave in the system. We are using the boot ROM functionality for updating the application software running on the 28069 target and the sequence (sending flash kernel, performing auto-baud, transferring the data) is controlled by the main MCU. We are not developing a boot loader on our own.

    It looks I was mistaken regarding the erase. I researched TI document called "Serial Flash Programming of C2000 Microcontrollers" and it tells that flash kernel is actually responsible for erasing and writing the flash memory. It also nicely states at which point the flash is erased by the flash kernel.

    Outtakes from the document:

    1. "Before any application data is received, the flash kernel erases the flash of the device readying it for programming."
    2. "At the beginning of the download process a key, a few reserved fields, and the application entry point are transferred
      before the actual application code. It is after the entry point is received that the kernel begins to erase the flash."

    So, I would like to ask the following:

    • What is the maximum time (worst-case) needed for the memory erase?

    I apologize for formulating my questions badly in the initial entry.

    Thank you!

  • Greetings  

    Please see the datasheet for details related to erase time.  Table 5-14. Flash Parameters at 90-MHz SYSCLKOUT, can get you started.  Here is a link to the datasheet.  

    Cheers!

    Krishna

  • Greetings Krishna Allam,

    The provided datasheet gave the answer to my question. However, there is a note in table 5-14 telling following about the maximum erase time:

    • The parameters mentioned in the MAX column are for the first 100 Erase/Program cycles.

    How can this be understood?
    Will the maximum time increase after those 100 Erase/Program cycles?

    Thank you!

  • Hi Lev Avdejev

    Thanks for confirming that the datasheet answers your question.  So typically, in an embedded system, a developer will use RAM and RAM based application builds to debug and complete the software development cycle.  Once the development is nearly complete, the application is programmed into flash.  As you may already know, flash will degrade over time (over a very long time).  So the note about the 100 Erase/Program cycles is a guaranteed worst case number.  The MAX time may remain the same after that as well. 

    What are your requirements?  Please let us know about your specific concerns. 

    Regards,

    Krishna 

  • Hello Krishna Allam,

    Yes, I am aware about the issue with flash aging.

    We do not have direct requirements for this. Our goal is to implement a timeout mechanism to cancel the software update process in case of communication problems with the boot ROM. Taking into account that most likely the 100 erase/write cycles will not be achieved during the product's lifetime, then it makes sense to use the maximum time specified in the datasheet.

    Thanks for clarification and help!

    Lev