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.

Simple flash uploading to TMS320F28035 over SCI

Other Parts Discussed in Thread: TMS320F28035, CONTROLSUITE

The document SPRUGO0a is complete, but confusing. It does not make it immediately clear just how simple it is to flash your code using SCI communication. You do not need to write anything to Flash your code, you do not need to call the Boot Rom API, you do not need to include Boot API symbols in your code, or do anything in your application to communicate with the SCI port for loading. You do not need to write a RAM-based boot loader, or copy anything flash-related to RAM at run-time The Boot ROM inside the TMS320F28035 already does everything you need to place your code into flash memory. Here's what you do:

  1. Take your program that you want to flash (for example program.out) and prepare it for SCI bootloading with the HEX2000 utility:
             C:/ti/ccsv5/tools/compiler/c2000_6.1.1/bin/hex2000 -boot -sci8 -b program.out
    HEX2000 will create a binary file called program.b00.  This is the file that you will dump into the F28035 serial port.
  2. Power up F28035 with pins set this way:
    • TRST = 0
    • GPIO37 (a.k.a. TDO) = 0  
    • GPIO34 (a.k.a. CMP2OUT) = 1
    These settings tell the F28035 bootloader to flash what it receives on the SCI port.
  3. Use a terminal program on your PC (I use RealTerm v2.0.0.70), but first send the character A (or a) to establish the baud rate. No other characters will do! If the F28035 understands you, it will echo the same character back. If it does not understand you, reset at step 2 then try a lower baud rate. 38400 baud or lower works for me.
  4. Now dump the file program.b00 to the F28035. It will echo back every character. This will look like garbage. Ignore it (or compare it for accuracy).
  5. When the file has finished sending, the F28035 will begin executing your program, based on the start address embedded in the .b00 file.
  6. Now keep GPIO37 = 1 all the time, so at reset your program will run instead of the bootloader. Later if you want to reflash a new program, reboot with GPIO37=0 again and the serial bootloader will be waiting for you.

This is the simplest way to upload and run a program. Hope this helps someone.

  • Murray,

    Murray Kopit said:
    . You do not need to write a RAM-based boot loader, or copy anything flash-related to RAM at run-time The Boot ROM inside the TMS320F28035 already does everything you need to place your code into flash memory

    thanks for the details. The steps you listed will work well for a RAM based application (as long as program.out is all linked to RAM). One cannot program flash using the above steps, because the ROM loaders on the device don't support flash programming yet. User applications have to take care of that.

    Users will have to write a kernel (a RAM based application that calls into flashAPI library (via either ROM linkage or direct API libs linkage)) to program the application in flash. This kernel will also have to take care of how it can receive the application data - via SCI/any peripheral. Depending on the application size if it can fit in RAM user can decide to load it onto the device along with the kernel.

    Best Regards

    Santosh

     

     

  • Hi Santosh,

    Thank you for your feedback. I see now that I was premature in my advice, that it only applies to a RAM located application.

    In my product, I must flash a F28035 from a binary image stored in another microprocessor. So, I first upload over SCI a RAM bootloader, based on your example in C:\TI\controlSUITE\libs\utilities\flash_api\2803x\v100a\example_ccsv5. My RAM bootloader will then upload and flash over SPI my DSP program, using a CRC checker and retry scheme which I am about to write.   Do you know of any code which already exists to do this?

    Thanks,
    Murray

  • Murray,

    what you say is perfectly possible. Load the 'SPI_kernel' over SCI and once the SPI kernel starts it will downlaod and flash the application over SPI interface. Unfortunately we don't have an example for that. We are working towards providing such examples but they wont be coming out soon enough.

    I can however assist you in your development if that is of any help, what you are looking for is below.

    > an application that calls back in the FlashAPI in ROM to be able to program data/code into flash - TI releases Flash API ROM symbols library and SW flashAPI library. Take a look at http://www.ti.com/tool/sprc907 this explains how to use it pretty clearly. If you have any questions please let us know.

    > the application should be able to receive and decode the data over SPI and program the data into flash. Here the data format coming into the device is your application dependent, you are welcome to reuse the SPI ROM loaders code/format here - its pretty simple and versatile. TI releases ROM sources for this use. If you look into the ROM laoders they decode the data and program data into RAM based on the destination address in the incoming data header, right after the loader function decodes the data and finds out the destination address you will have to call respective flash API to program it into flash, if the destination address is flash.

    hope it helps, please let me know if you have any further questions.

    Best Regards

    Santosh

     

     

  • Dear Santosh/Murray,

    Does this mean that if we use the method specified by Murray, and lets say we power off the device, then on turning it ON again, it won't run the latest flashed program?

  • Hi guys,

    Just a comment: After hours I was not able to get this working with TerraTerm. No problem with RealTerm. Correct me if I’m wrong but I don’t think it is working with TerraTerm. It probably sends the data from the x.b00 file in a different way.