• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 82 subscribers
  • Views 1587 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.

TMS320F28075: USB Boot Mode

Stanley Adams
Prodigy 50 points
Part Number: TMS320F28075
Other Parts Discussed in Thread: C2000WARE

Good day,

I am looking for a way to make it possible for end-users to update firmware. Preferably this would be over USB, as most people

have USB cables available. As far as I can see, the 28075 has a built in USB bootloader that works in a similar way to the SCI

bootloader which I have used successfully, which is great news until I saw that to enable USB boot mode it is necessary to write

to the BOOTCTRL register which is OTP. As far as I can tell, this means that once USB boot mode is selected it is impossible to

boot to flash ever again. This makes the USB boot mode completely useless. Surely you want to be able to change the boot mode

to USB by writing to a non-volatile register (in flash for example) then reset the device into USB boot mode. Once the firmware

update is complete you want to over-write that register to change the boot mode to flash before resetting the device again.

I cannot think of any good reason for the BOOTCTRL register to be OTP.

Is there any solution to this problem other than writing my own bootloader application that is stored in flash?

Regards,

Stanley

  • 0
    TI__Mastermind 30255 points
    Stanley

    You don't need to change the BOOTCTRL boot mode setting to return to flash boot. With USB bootloader (as well as others including the other two possible default options Parallel and SCI bootloaders), if the first data word of the received message doesn't contain the correct key, it will exit the bootloader and boot to flash.
    If you'd like to look at the code, the bootloader source is in C2000Ware.

    Best regards
    Chris
  • 0 in reply to Christopher Chiarella
    Prodigy 50 points

    Thank you for the quick response Chris.

    Maybe I am missing something, but surely for a data word to be received via USB, there must be something

    connected to the device via USB. So in the case where nothing is connected and BOOTCTRL has been setup

    so that Get Boot mode is USB, the device will go into USB boot mode and do nothing.

    Is there perhaps a timeout that I am unaware of, after which it boots to flash?

    Regards,

    Stanley

  • 0 in reply to Stanley Adams
    TI__Mastermind 30255 points
    Stanley

    Correct, it will wait until USB receive buffer is filled so will need a connection. For the case where you don't want anything hooked up and to boot to flash, then your best option to implement the bootloader in flash.

    Best regards
    Chris
  • 0 in reply to Christopher Chiarella
    Prodigy 50 points

    Thanks for confirming my suspicions Chris.

    It just seems that all the Get Boot mode options would be much more useful if BOOTCTRL was just not OTP. Otherwise you have all these built-in bootloaders that are great but useless in many cases.

    Is it possible to jump to the boot rom from a user application without a reset? If so, I could just add a jump to the start of the USB bootloader that is in ROM when a PC is connected via USB and I want to start a firmware update.

    Regards,

    Stanley

  • 0 in reply to Stanley Adams
    TI__Mastermind 30255 points
    Stanley

    Agreed, unfortunately it doesn't help your current situation, but these are items that led to boot customization improvements on our latest devices. If you're interested: http://www.ti.com/lit/spraca2

    Yes, you can call the USB bootloader from ROM in your application. Include the ROM symbols lib provided in C2000Ware into your project and then you can use the "USB_Boot()" function. Refer to the source code for parameters and flow.

    Best regards
    Chris
  • 0 in reply to Christopher Chiarella
    Prodigy 50 points

    Thanks Chris,

    I will try loading the ROM symbols as you have suggested. I have verified that the USB bootloader works very well by using the EMU_BOOTCTRL register while I had an emulator connected so now, hopefully, I only need to make my program jump to the correct ROM location.

    Regards,

    Stanley

  • 0 in reply to Stanley Adams
    Prodigy 50 points
    Ok, So I thought I would document this here in case anybody else is interested. I included the ROM symbols library F2837xRevB_c1bootROM_BootROMSymbols_fpu32.lib into my project.
    I also had to include c1_bootrom.h
    There were a few problems because it seems that the code supplied in C2000Ware was copied from the 2837x,
    so there were includes that would not work until I changed them to reference to correct 2807x headers.
    Once all the references were sorted out and it would compile, I added the following:
    USB_Boot(0x0C5A); - As far as I can tell from the source code, the argument is not used and can probably be any value

    Running this code, the USB device was detected and I could start the bootloading process, but as soon as the flash API
    was finished loading the device would disconnect and the process would be interrupted. I found that it was actually
    just continuing with the next line of code in my project once the flash API was loaded, instead of jumping to the start
    of the flash API in RAM. So I just added a jump to the start of RAM at address 0x00 and that solved it.

    So my code looks like this:
    USB_Boot(0x0C5A);
    asm(" LB 0x00");