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: Performing a DFU from Flash memory using serial_flash_programmer

Part Number: TMS320F28052F
Other Parts Discussed in Thread: CONTROLSUITE, C2000WARE

I need to be able to perform a DFU to my TMS320F28052F through a serial connection (RS-485) using pins 49 and 48 (which correspond to GPIO7 and GPIO12 respectively). 

The initial approach was to boot the device in SCI mode and use controlSUITE/C200Ware's serial_flash_programmer utility, but when the device boots into SCI, the mapping of the pins for SCIRXDA and SCITXDA are to their respective locations at pins 41 and 42. These pins are currently used as SCLA and SDAA ports. 

It has been suggested to me to keep the SCI kernel (which I assume is the .txt file found when compiling the example project from C:\ti\controlSUITE\device_support\f2805x\v104\F2805x_examples_ccsv5\f28052f_flash_kernel) in flash, then copying it to RAM while the device is in a regular boot mode, then executing the programmer using pins 48/49.

I've viewed some related threads to this subject:

https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/155583/681411#681411

e2e.ti.com/.../864118

However, under controlSuite/C2000Ware's libraries, there are no boot_rom sources for me to reference (as it was mentioned in above threads). 

I guess my initial questions are as follows:

-What portions of a code would I need to edit/include to enable branching to SCI boot but maintaining the "regular" boot pin map?

-Once the SCI kernel is saved to flash/code edited as needed, how would I implement the serial_flash_programmer with this new setup?

This is all pretty unfamiliar territory for me, so any insight or direction would be much appreciated,

James 

  • Hi James,

    You can simply use the F2805x SCI flash kernel and build it to use the SCI pins you need. Once the DFU function is signaled, you can copy the kernel to RAM and execute.

    The only thing you would need to change in the serial flash programmer is to skip the F05_downloadKernel() funciton. You would need to rebuild the serial flash programmer and simply skip the part which downloads the kernel, and proceed straight to downloading the flash application which communicates with the sci flash kernel which has already been loaded to the device and copied to RAM.

    Hope this helps.
    sal
  • Hey Sal,

    This is incredibly helpful. Do you think you could elaborate on how a "DFU function is signaled" and how I can save the kernel in flash/copy the kernel to RAM?

    Thankfully,
    James
  • You would need to signal the DFU function in your system. Perhaps a pin is set high or low, or the device receives some sort of command from a communication peripheral. This is entirely up to you.

    Once your system is signaled that it is ready to receive a DFU, then you can copy the kernel to RAM. To do this, put the necessary kernel code in a #pragme CODE_SECTION() and then copy that section to RAM. Then call the kernel function which you just copied to RAM.

    You only need to make sure that the flash API and the code which calls the flash API is run from RAM. That is what matters the most.

    Regards,
    sal