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.

TMS320F2806x - Bootloader without GPIO

Other Parts Discussed in Thread: CONTROLSUITE

The following solution uses GPIO with a bootloader to download code to TMS320F2806x.

https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/230106

 Is there a software-only option(i.e. without using GPIO) for downloading application code over SCI?

Thanks!

  • Hi,

    When you say software-only option, do you mean to say that you don't want to use the boot mode GPIOs to get to SCI boot? If yes, then there is no zero-boot pin option available for F2806x. I confirmed with our BootROM expert.

    Thanks and regards,
    Vamsi
  • adding to what Vamsi said, you can program a loader in user OTP and always boot to user-OTP (you will still need to pull the boot mode pins to GETMODE) and in user OTP you can check if you want to start SCIBOOT or boot to an existing application in flash if one was available in flash.

    You can also refer to a flash programming kernel example available in controlSuite for information on how to program flash using SCI. C:\ti\controlSUITE\device_support\f2806x\v151\F2806x_examples_ccsv5\f28069_flash_kernel

    Best Regards
    Santosh Athuru
  • Vamsi Gudivada said:
    Hi,

    When you say software-only option, do you mean to say that you don't want to use the boot mode GPIOs to get to SCI boot? If yes, then there is no zero-boot pin option available for F2806x. I confirmed with our BootROM expert.

    Thanks and regards,
    Vamsi

    Correct link that I referred to in my original post is this. Sorry about that.

    http://processors.wiki.ti.com/index.php/C2000_Bootloader

    A software only solution will not use the state of the GPIOs(as mentioned in link above) to switch to download mode.

    Instead of looking for the state of a GPIO at bootup, is it possible to look for certain custom ASCII characters over SCI at bootup? If so, Is this a solution previously used and could you post any links?

    Thanks

  • Hi,

    I saw the wiki link that you pointed. In F2806x, you need to use the boot mode GPIOs to tell the device bootloader to either go to SCI boot or other modes (like get mode).

    Flash kernels that Santosh pointed can be used if you want to program Flash. SCI Bootloader is used to download the Flash kernel in to the device RAM and then the Flash kernel will take over to program Flash with the data received from the SCI port. This method uses the boot mode GPIOs to select SCI boot. Here is a document that you can refer to in case if you want to use the Serial Flash programming kernels: www.ti.com.cn/.../sprabv4a.pdf

    Thanks and regards,
    Vamsi
  • Hi Vamsi,

    Thanks for the link.

    Unfortunately, any of the GPIO based solutions wont fit our application.

    Let me rephrase my earlier question. To switch between the modes(SCI boot, get mode, etc), the bootloader code probably inspects the state of the GPIO pin at bootup. So, instead of checking the state of this GPIO pin, is it possible to write a custom Bootloader code that will look for a custom ASCII string (For instance, a string of 20 ASCII characters) and then switch modes?

    Thanks,
    Jameel
  • Jameel,

    You can program a custom loader in the USER OTP that can look for a custom string to decide on the boot mode. However, you still need to use the Boot mode GPIOs to reach USER OTP boot option (through Get Mode).

    Thanks and regards,
    Vamsi
  • Vamsi,

    would there be a way to have the GPIO set by some pull up/down resistors all the time, and have a custom loader which would wait for a period of time searching for a custom string? if it received the custom string it would know that it would need to write new firmware to the device, and if it didn't receive the string after a period of time then it would jump to the application code already in the device? I was thinking this would be a solution to be able to bootload new firmware in the field without having to manually set GPIO. Thanks for your input!
  • Greg,
    Internal pull-up/down are not possible, you will need external pull up/pull down resistors on board for the boot mode pins so the device gets into your needed boot mode. If you don't need to change the boot mode pin configuration then you can leave them like that on the board without ever having to touch them. When the pin is assigned to a peripheral function later on in the application the external weak pull-up/pull-down can be usually over ridden by the peripheral function.

    This way you can get to OTP BOOTMODE or FLASH BOOT and have your loader called always which will check the FW update string.

    Hope this helps.

    Best regards
    Santosh Athuru
  • Santosh,

    Yeah, that's what I was thinking we could do, using external pull up/down resistors. This way the every time the board boots up it will check to see if it needs to update the firmware, and if it doesn't need to (doesn't get the specified string) then it will load the code currently in the chip.

    Are there any examples that could be used for a custom flash bootloader? Thanks for your response!

    -Greg w.
  • Santosh,

    As suggested in the link below, would OTP_KEY==0x005A and OTP_BMODE==0x01 be used programmatically to enter SCIBOOT mode? Would this be programmed in the bootloader code or one time in application code?


    Excerpt from the link(processors.wiki.ti.com/.../Emulation_Boot)
    Q: Are there differences between the SCI Boot selected by hardware ( GPIO pins ) and selected by software ( via GetMode())?

    There is no difference. SCIBOOT using GPIOs and using GetMode() behaves the same (uses the same loader).

    Stand-alone boot
    SCI boot can be selected in two ways:

    1. By configuring the boot mode GPIO(s): (TRSTn == 0 && GPIO37 == 0 && GPIO34 == 1) == SCI_BOOT
    2. By Configuring the boot mode GPIO(s) for GetMode() and programming OTP_KEY==0x005A and OTP_BMODE==0x01.




    In either case, this solution or the custom ASCII string suggested by Greg above, an example that uses a custom bootloader will definitely help.

    Thanks for the feedback.

    Regards,
    Jameel
  • Greg,

    yes , please refer to the below example in controlSuite. You might have to modify the SCI_Boot.c functions to see if you want AutoBaud Lock to be there or not and if it doesn't autobaud lock then timeout, things like that. You might want to add the string check here,

    C:\ti\controlSUITE\device_support\f2806x\v151\F2806x_examples_ccsv5\f28069_flash_kernel

    The example as of today waits for ever for Autobaud to lock, but once auto baud locks it will look for specific keys from the incoming data (C2000 HEX format) and parses the incoming data and programs flash accordingly. The loader expects the application coming in to be of C2000 HEX format.

    Also the ROM code for the device is also provided in controlSuite for study/understanding the boot. You don't have to rebuild the boot ROM project but you can just load the symbols and step through the ROM code.
    C:\ti\controlSUITE\libs\utilities\boot_rom\2806x\2806x_boot_rom_v1_1

    Also please refer to the boot ROM chapter of TRM to understand the hex format expected by the loaders.

    Best Regards
    Santosh Athuru
  • Jameel,

    yes, if you program OTP_KEY as 0x005A and OTP_BMODE as 0x01 then you will enter the SCI BOOT in ROM which is same as when you pull the GPIO37 LOW and GPIO34 HIGH with TRSTn LOW.

    If you want to implement customer loader in flash, then leave the OTP_KEY and OTP_BMODE as unprogrammed and pull both the boot mode select pins HIGH, this will get the program control to the custom loader in flash.

    If you want to program the custom loader in OTP, then program OTP_KEY and OTP_BMODE as BOOT TO OTP and pull both the boot mode select pins HIGH, this will get the program control to custom loader in OTP.

    The SCI_BOOT in ROM waits for Auto Baud to lock and then looks for a ASCII string and if it doesn't match then it will default to flash. The only difference between this and your requirement is that wait for Auto Baud lock before it reads the characters. Please study the ROM source code for clarity.

    Best Regards

    Santosh Athuru