• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 81 subscribers
  • Views 142 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.

TMS320F28035-EP: GPIO boot resistor design question

Jeffrey Masse
Intellectual 360 points
Part Number: TMS320F28035-EP
Other Parts Discussed in Thread: C2000WARE

When a new F28035 requires code, you can pull up GPIO37 and pull down GPIO34 to configure boot mode to SCI. So a new F28035 without code will sit and wait until a hex file is loaded via SCI. Once code is loaded, the resistors haven't changed and would effect all future power on cycles. What do designers typically do for these 2 pins because I believe they would be sampled by the bootloader before you could configure them as outputs. Do designers typically use headers and jumpers for the first code load so that on the next power cycle removing the jumpers removes the pull up and pull down resistors form the GPIO inputs?

  • +1
    TI__Guru 71815 points

    Jeffrey,

    I'd recommend looking at this application note https://www.ti.com/lit/spracn1 that addresses this issue through SW control of the boot flow so that you don't have to make HW changes when you want to switch boot modes.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Intellectual 360 points

    For those who stumble on to this issue, look at sections 3 and 4 of the spracn1 document mentioned by Mathew. Thanks for the help!

  • 0 in reply to MatthewPate
    Intellectual 360 points

    I'm sorry to bring this back up but I still am missing something.
    On a new unit the F28035 has no FW, just its native bootloader.
    We design the GPIO to be able to load the FW for the first time via SCI.
    The FW is uploaded into RAM, copied over to flash and begins execution.
    Now the system is powered down.
    On the next powerup, the InitBoot and SelectBootMode are still going to see the GPIO pins as being in SCI bootloader mode. Any previous SW configuration of the SCI GPIO pins, pullup, output etc, are wiped.
    What has to happen in the FW load that is going to make the F28035 jump to Flash instead of SCI bootloader?

  • 0
    Intellectual 360 points

    Part Number: TMS320F28035-EP

    Initial question was here but I hastily approved the answer.
    e2e.ti.com/.../3784095
    There is a big difference between a software reset (accidentally approved answer) and a power cycle - what I am seeking to resolve.

    On a new unit the F28035 has no FW, just its native bootloader.
    We design the GPIO to be able to load the FW for the first time via SCI.
    The FW is uploaded into RAM, copied over to flash and begins execution.
    Now the system is powered down.
    On the next powerup, the InitBoot and SelectBootMode are still going to see the GPIO pins as being in SCI bootloader mode. Any previous SW configuration of the SCI GPIO pins, pullup, output etc, are wiped.
    What has to happen in the FW load that is going to make the F28035 jump to Flash instead of SCI bootloader?

  • +1 in reply to Jeffrey Masse
    TI__Guru 71815 points

    Jeffrey,

    Saw your other post, I'll combine it with this thread so we can keep things together.  Also sorry for the delay, I meant to reply before end of day on Friday.

    Appreciate the details of your application, referring to the previous app note it was approaching that the default was boot to flash, then based on some messages from the system would change to the SCI bootloader for updates, and then reboot back to flash.  This doesn't address the initial programming, assuming it is done as part of the manufacturing flow; likely using JTAG to burn the initial image to the flash.

    Bear with me a bit, I'm going to suggest a few different things, and we can brainstorm on what is possible with your system:

    In your case, you need the SCI boot for the initial program(and any updates), but then boot to flash most of the other time.

    Looking at the ROM source(C:\ti\c2000\C2000Ware_3_04_00_00\libraries\boot_rom\f2803x\v1_0\rom_sources\source) there is no timeout contingency(unfortunately), but there is a key compare as follows:

      if (SCIA_GetWordData() != 0x08AA) return FLASH_ENTRY_POINT;

    Would there be a way for something on the board to get the boot code through the autobaud lock and give an invalid word when there is no FW update?  Or is the UART update simply done when the PC/Host is connected to a PCB header?

    If the above is not feasible would it be possible to tie the connection to the host to the PCB to drive a boot pin to force the SCI boot when connected?  Referring to the boot table below; we can see that SCI Boot has a dedicated mode defined by the Boot pins.  The difference in this and GetMode(which would be flash boot) is that GPIO37 needs to be driven low for SCI boot and high for GetMode.

    So the board would have PUs on GPIO37 and GPIO34, and when the host is plugged into the PCB it would overdrive the PU on GPIO37 low forcing the SCI boot.

    I've got a few other ideas, but want to get your thoughts on the above.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Intellectual 360 points

    Thanks Mathew - you confirmed my suspicion that hard designing the resistors for SCI load of firmware will be interpreted on every subsequent power up of the board. To add a little complexity, once the board is loaded with initial FW via SCI and installed into the system, any future update will be done via CAN bus and that process has been resolved. Since CAN bus is the boards only future communications, I cannot send a 'fake key' via SCIA to force a return of FLASH_ENTRY_POINT. 

    I do like your suggestion regarding creating a special connector for the SCI port so that when it is plugged into the board, powering the board will bring it up in SCI boot mode since GPIO37 will be forced to low and when the connector is removed, GPIO37 is high which will revert to GetMode which defaults to Flash as long as there is an unprogrammed OTP.

    This seems like the most likely solution but I would be open to hearing others if you are bored ;-)