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.

Boot F2806 from either CAN or SCI

Other Parts Discussed in Thread: CONTROLSUITE

Hi

for a project with a piccolo F28069 I need to boot from either CAN or SCI (or of course to jump directly to the application). Is there a way to do it? If yes, what GPIO/states are involved?

I tried to find it out here:
http://www.ti.com/lit/ug/sprugo0a/sprugo0a.pdf

but it is not clear to me the how the bootloader jumps to the application in each of the 3 cases:

1)  GPIO37=0, GPIO34=1 -> SCI boot
2)  GPIO37=1, GPIO34=1 -> GetMode (OTP selected for CAN)
3)  boot to application ... how do I boot normally to flash???

I'm probably missing something trivial...

Thanks for your help!

  • Caleg,

    Section 2.2.9 of the TMS320x2806x Piccolo Technical Reference Manual (http://www.ti.com/lit/pdf/spruh18) describes the GetMode. In short, the default behavior of GetMode will boot to Flash. You can program the OTP to define GetMode to boot differently.

    Regards,
    Dave Foley

     

  • Thanks Dave for the quick reply.

    I've read the chapter. What I don't get is how do I boot to flash (jump to my application) once the OTP is set to CAN.

    Could you please explain me that?

    Regards,

    Caleg

  • Caleg,

    Sorry, I didn't scrutinize your question close enough. It's not clear to me what defines when you need to boot via SCI, when you need to to boot from CAN, and when you need to boot from Flash, but maybe I don't need to know that. If you need to swap between SCI and the other two, obviously you can just change the pin settings. However, both booting from Flash and booting from CAN can only be acheived via the GetMode and you can only program one choice in. It was not expected that an application would need to switch between the different modes. However, what you could do is create a small kernel in Flash that checks some pin of your choice to determine if it should boot to Flash or CAN, set the GetMode up to boot from Flash, and then using your kernel, either proceed on to your normal application in Flash or call the CAN bootloader in the boot ROM. There is nothing to prevent user code in the Flash from calling the boot loader functions. For a fresh device, the OTP_BMODE is already set to boot to Flash (0xFFFF). So, you wouldn't need to program the OTP. You would only need to program your boot kernel into the Flash along with your application. For a device that already has boot to CAN programmed (0x0007) you could reprogram the OTP to 0x0003, which would default to boot to Flash. Note, you cannot erase the OTP and program in a totally new value, but you can program additional bits. This is why this would work. In other words, if you tried to program the value 0x000F on top of an already existing 0x0007, it would not work because bit 3 needs to be moved from a 0 to a 1. However, you can technically program a 0x0003 on top of a 0x0007 because all you are doing is programming an additional bit (bit 2). Essentially, the one-time of OTP is at a bit level, not a word level.

    Regards,
    Dave Foley

     

  • Hi Dave

    Thanks for all the info. There is still something (more basic) not clear to me in the boot process. I try to explain what I do not understand...

    In fact for my question you can skip the SCI part (it is anyway selectable via GPIO).

    1) Lets suppose that only the "CAN_BOOT" option is selected. What does the bootloader do, when no firmware upgrade is forseen? Does it remain into boot waiting for data? If not, what is the trigger that makes it jump to the application?

    2) I might have misunderstood the FLASH_BOOT option. What does it mean? Is it a firmware update from flash?

    Thanks again for your support.

    Regards,

    Caleg

  • Caleg,

    1) I believe the CAN bootloader will continue to wait for a valid CAN bootloader KeyValue described in section 2.2.20 of  SPRUH18D. It expects the entry point to be given over CAN as bytes 19-22 in Table 2-15. I don't believe there is a timeout that eventually causes it to boot to Flash. You can find the entire boot ROM source code in ControlSuite (Devices->Piccolo F2806x->Supporting Libraries) if you want to understand the exact behavior. If you truly need a timeout, you may have to build your own boot loader and embed it into Flash. You could use the ROM bootloader as a starting point and put your own hooks in. Then you program in that code into Flash and setup the GetMode to FLASH_BOOT (or boot to Flash as I've been calling it). Or, as I said previously, you can just program in a call to the boot loader from your main application when you want to run the CAN bootloader.

    2) The FLASH_BOOT is described as "Jump to branch instruction in flash memory" on pg 206 in SPRUH18D:

    "Jump to branch instruction in flash memory. Jump to flash is the default behavior of the Get Mode boot option. Jump to flash is also available as an emulation boot option. In this mode, the boot ROM software configures the device for 28x operation and branches directly to location 0x3F 7FF6. This location is just before the 128-bit code security module (CSM) password locations. You are required to have previously programmed a branch instruction at location 0x3F 7FF6 that will redirect code execution to either a custom boot-loader or the application code."

    It essentially just jumps straight to your entry point in Flash. It is the expected way that most users will boot in production.

    Regards,
    Dave Foley

     

  • Thanks, I'm getting closer to solve my problem.. :-)

    Let me rephrase what I've read to make sure I have understood the SPRUH18D correctly...

    1) In CAN_BOOT (which behaves like the SCI_BOOT) if the bootloader receives via CAN something different from 0x10AA, the bootloader exits and jumps to the application.
    Correct?

    2) FLASH_BOOT simply jumps to the user application. -> ok, that's clear

    Thanks again,

    Caleg

  • Caleg,

    Yes! Good catch. I forgot that if the KeyValue received is not correct it jumps to Flash. Although, I believe the correct value for SCI and CAN is 0x08AA, not 0x10AA.

    Regards,
    Dave Foley