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.

TMS320F28052F: Actions taken upon failed checksum

Part Number: TMS320F28052F

Hello, I have been working on implementing the serial flash programmer utility in a DFU application for motor drives. I have been successful in this largely due to the feedback provided by the e2e community and am in the process of adding final touches on the project.

As of now, if the serial_flash_programmer -> f05_DownloadImage has a failed checksum, it returns "12" which signals an exit code to halt the application. This could leave half-written code in the micro's flash which could prove to be destructive in my project if run. Since the setting in which my application will run may be subject to significant noise, there is the possibility that noise causes corruption in some of the blocks to be written to flash.

What I was hoping to do involves restarting the erase and application download process or just erasing all of flash and leaving it blank if a checksum error occurs. I would prefer to possibly branch back up to the application autobaud to re-establish a connection with the drive, then doing a fresh download of the application file. However, if this is not possible, I would rather have the micro be erased instead of having possibly destructive code in it. 

Are either of these two options viable, and if so, what would be the best method moving forward? Is there an error code I can have thrown in the programmer that signals the kernel to restart the download process/erase flash?

Our leading idea involves sending some sort of command to the micro so that it branches back to the autobaud but we do not know how to do this in such a way that it cannot be interpreted as a block write.

Thanks for any and all direction,

James

  • Hi James,

    We're looking into this. I will respond again when I have good suggestions for you. Thanks for your patience through this.

    Regards,
    Elizabeth
  • Hi James,

    The Technical Reference Manual has a chapter on the bootloader format. Also, the Serial Flash Programmer Application Report (AR) has some information on the communication protocol used.

    www.ti.com/.../sprabv4b.pdf

    You are free to modify the host and device code to achieve this goal.

    When the device is receiving data for a DFU, it will continue to receive blocks of data until the block size is 0x0000. Once this occurs, the kernel will branch to the entry point of the image just downloaded and programmed. At this point you can modify the code to have the host and device communicate to perform some other function.

    Hope this helps.

    Regards,
    sal