• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 552 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Bootload a C5535 when SPI flash has been erased

Susan Williams
Intellectual 385 points
Other Parts Discussed in Thread: CODECOMPOSER

I have been working on writing code to reload the SPI flash for our custom design using the C5535, because we want to be able to update the product in the field.  I had succeeded in loading a .bin file and writing it to the top half of the flash (starting at 0x40000), so I gave a try at copying the data to address 0 as I would need to do for an actual firmware update.  I seem to have bricked the device--the emulator won't connect to it anymore to burn the flash via CodeComposer (complains that address 0 is 0).

I have the Using the Bootloader document, and the UartBoot.exe and usb_boot.exe.  Neither of these programs seems to work.  When I run UartBoot.exe, it gives this helpful error message: ERROR: Could not send data !!  (I am using 57600 baud rate.)  When I run usb_boot.exe, it complains: "The program can't start because WDAPI1010.dll is missing from your computer. Try reinstalling the program to fix this problem."

I have a serial program I wrote that uses the serial port to push the data over--if I reconfigure this to just push the data to the uart (using the info in Using the Bootloader), it seems to connect to the serial port but hangs trying to send data.

Any help on using either UartBoot.exe or usb_boot.exe?

  • 0
    TI__Mastermind 30140 points

    Hi Susan,

    If you have programmed your SPI Flash, because of the its precedence in the boot order, the bootloader (running from ROM every power-on-reset) will see the valid boot signature in the SPI Flash, and try to boot from it.

    USB boot and UART boot do not get executed until after checking SPI for a boot image/ boot signature.

    See the bootloader document:

    "Each device has a fixed order in which it checks for a valid boot image on each supported boot device. The device order is 16-bit SPI EEPROM, 24-bit SPI serial flash, I2C EEPROM, and SD/SDHC/eMMC/moviNAND. The first device with a valid boot image will be used to load and execute
    user code. If none of these devices has a valid boot image"... ..."Next the bootloader goes into an endless loop checking for data received on either the UART or USB."

    You can disconnect the SPI flash by moving DIP SW3 Pin 4 to OFF.

    After powering on the board, you should be able to connect with CCS or use UART/USB boot.

    If you want to reprogram the SPI flash, switch DIP SW3 pin 4 back after power on and after the bootloader cannot find anything on the disconnected SPI Flash...

    Have you had success with the USB boot before (not having mising .dll errors)?

    Hope this helps,
    Mark

  • 0 in reply to Mark M
    Intellectual 385 points

    Hi, Mark,

    Thanks for the response.  The problem I'm having is with a custom board, not the EVM.  We are wondering about the phrase "valid boot image" in the document--do you know what all it checks to see if the image is valid?  Is it just the first byte, or does it figure out if the whole image is present?

    The next day I was able to convince CodeComposer to talk to the chip, so it was not bricked.  I am still wondering about the two boot programs however.  Today we got in some new boards, so I was able to try them with a board that is unprogrammed.  I saw the same behavior--UartBoot.exe gives me the "ERROR: Could not send data !!" message.

    There are two issues we're interested in addressing.  The first is programming chips in manufacturing--we would prefer that assembly doesn't have to learn to use CodeComposer to program the boards!  We're looking into Spectrum Digital's programmer, but there appear to be some missing pieces (algorithm files) for this chip.

    The second is related to firmware update in the field: it is possible that a firmware update could fail, and we would want some way to reprogram the device without shipping it back to the factory.  If we could be sure the device would be left in an invalid state such that a program such as UartBoot.exe could be used to reload the RAM, the update could be restarted.

    Susan