• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 386 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F2800137: SPI bootloader and SPI flash kernel as secondary bootloader or SPI flash kernel as part of program

H F
Prodigy 90 points
Part Number: TMS320F2800137
Other Parts Discussed in Thread: C2000WARE

Tool/software:

We need to update and program the DSP via SPI via ESP 32. 

Firstly, there's a SPI bootloader inbuilt in the DSP , which saves the program into RAM. We first transfer our flash kernel , and once that runs, it saves our actual working program into the flash. The flash kernel is very much like SCI flash kernel example but with SPI, with checksum, and we even added our own delays between SPI byte by byte transfer.

The problem with the bootloader is , as it is inbuilt we cannot add features to it, nor can we debug it step by step. It is also written for SPI EEPROM Flash, and not a microcontroller like the ESP. It is very difficult to match timing of the bootloader to the ESP. The ESP misses the timing and the transfer fails. The only way we have been successful is by loading the entire file buffer into an array and sending it via ESP. If the ESP is even a microsecond late in processing , the transfer fails.

There is also no checksum or any acknolwdgement that lets us know the DSP  was programmed successfully. 

The flash kernel is about 15-16 kB, if we make a smaller SPI buffer ( eg of 16 bytes ) and keep reloading that, it misses timing.

Another idea was to have the SPI flash kernel be a part of our main program. But if it corrupts we have no way to update it in the field.

Is there a better way to utilise the SPI bootloader? What is the proper way to set it up with an ESP 32 ? 

  • 0
    TI__Mastermind 19520 points

    Hello,

    Thanks for you inquiry. Please allow for another day for me to make some suggestions - appreciate the patience!

    To summarize, you are able to utilize SPI boot mode (based upon the SCI example) and successfully can program the device, but the use case appears to be very narrow/particular in implementation (specifically for EEPROM) which is limiting. So you are asking for advice/guidance in implementing the SPI bootloader in terms of finding more flexible timing as well as being able to validate the program load?

    Best Regards,

    Allison

  • 0 in reply to Allison Nguyen
    Prodigy 90 points

    "So you are asking for advice/guidance in implementing the SPI bootloader in terms of finding more flexible timing as well as being able to validate the program load?"

    Yes exactly 

  • 0 in reply to H F
    TI__Mastermind 19520 points

    Hello,

    I'm still gathering input on this, but will provide an update tomorrow. Thanks again for the patience!

    Best Regards,

    Allison

  • 0 in reply to H F
    TI__Mastermind 19520 points

    Hello,

    Apologies for some delay in response. Regarding your earlier comment:

    H F said:
    nor can we debug it step by step.

    You can step through the device boot ROM by loading the boot ROM symbols (.out file) to the device.  Loading symbols can be a valuable debug method. This option adds the symbols available in the generated project '.out' file for debugging purposes instead of loading the actual '.out' program onto the core via CCS - this is also why you can use this method with the boot ROM/built in bootloaders to debug and get visibility.

    1. Open CCS to a workspace
    2. Click 'view' > 'target configurations':
    3. You can import a project for this device to CCS and use that to connect to the device, or copy the raw target config from C2000Ware to the "user defined" target configurations in this window. Either way, find the device target config (example for F28377D below) and launch it:
    4. When it brings up the debug window, select the device CPU and connect to the target:
    5. Navigate to the toolbar and click the button to "load symbols"
    6. Load the bootrom .out file. For this device, it should be in 
      1. C:\ti\c2000\C2000Ware_5_02_00_00\libraries\boot_rom\f280013x\revb\rom_sources\ccs_files\cpu\Release
      2. If a window pops up saying it can't find the source file, you can select "Locate File" and find it in C2000Ware
        1. Usually here C:\ti\c2000\C2000Ware_5_02_00_00\libraries\boot_rom\f280013x\revb\rom_sources\F280013x_ROM\bootROM\source
    7. The file should open to show the location of the bootrom you are at, and you can step through/debug

    Let me know if you try it - there are also likely other threads that have instructions on how to do this as well. Regarding the remainder of the inquiry, I am still trying to gather more information to see what other suggestions may be helpful here and will let you know when I can provide an update.

    Best Regards,

    Allison

  • 0 in reply to Allison Nguyen
    Prodigy 90 points

    Thank you for this. To debug and test, we used the spi boot file in bootrom and kind of made a ccs project around it. It worked well. Can you please get back to us about the checksum ? And whether we can make changes in the bootloader

  • 0 in reply to H F
    TI__Mastermind 19520 points

    Hello,

    Glad you were able to debug and test! If you are using the built in SPI bootloader and booting to SPI, you are limited to what is in the boot ROM, and for SPI there is no inherent hardware check feature available, but let me verify if there is any other flexibility or solution here and provide an update tomorrow.

    Best Regards,

    Allison

  • 0 in reply to Allison Nguyen
    TI__Mastermind 19520 points

    Hello,

    Apologies for the weekend delay - just wanted to let you know I unfortunately haven't been able to garner much more information yet. But let me reach out to a few more resources. I'll be sure to follow up in the next 1-2 days.

    Best Regards,

    Allison

  • 0 in reply to H F
    TI__Mastermind 19520 points

    Hello,

    Sorry for the long delay - to confirm what I mentioned before, if you are using our SPI bootloader, there is no way to get around the what you are using from the bootROM unless you developed your own custom bootloader. This case is unfortunately limited in that respect, but I've documented this to give feedback to our bootROM team. 

    Best Regards,

    Allison