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.

TMS320F28335: Custom Bootloader

Part Number: TMS320F28335


Hi everyone,

Good Evening...!!!

I developed a custom bootloader which is placed in Flash Sector A. The actual application code is later flashed by the help of custom bootloader in Flash Sectors B,C,D,E,F(Application code and Custom bootloader are two separate  hex files).

Custom bootloader is flashed by the help of JTAG and application code is flashed by the help of custom bootloader.

The sequence of operation is:

1. ROM bootloader(On power on)

2. Custom bootloader(ROM bootloader branches to 0x0033FFF6 where custom bootloader initial address is placed)

3. Application code(Custom bootloader waits for 5Sec and then jumps to codestart.asm of application code if no new code is found)

Question:

Now, when application code is flashed(Using Custom Bootloader) and rebooted, for the first time custom bootloader is not jumping to application code and from 2nd time onwards, it jumps very smoothly. Can anyone please tell why this behavior is observed...?

Thanks in advance...!!!

Regards,

RS

  • Rahul,

    1. Which peripheral does the custom bootloader (CBL) use? 
    2. After the CBL is programmed , is the JTAG connector disconnected? Is this behavior seen with the JTAG connector disconnected? 
    3. If it is not jumping to application code, what exactly is the device doing?
  • Hi Sir,

    Thanks for the reply...!!!

    My comments on your points:

    1. CBL uses SPI to connect with the card (ENC28J60 - Ethernet Card).

    2. Yes, The JTAG is disconnected and then the behaviour was observed.

    3. I am not able to find what exactly it is doing? Can you tell me a way to track where exactly it is and what it is doing...? I am sure it is not executing any application part.

    Thank You,

    Regards,

    RS

  • Rahul,

                  I can provide some suggestions but it is hard to debug issues like this without access to the hardware.

    You could toggle a GPIO pin in your custom bootloader. This way, when your code does not branch to your main application (after waiting for 5 seconds), you can at least confirm the device is still in the CBL and is not lost somewhere. If you have more than one GPIO pin available, you could toggle different GPIO pins in different parts of your CBL in order to more precisely determine the extent to which your CBL was executed.

    Another thing to look into is whether your code waits until the PLL is locked, the first time.

    Are you leveraging the SPI loader in our boot-ROM or have you written your own SPI loader?

  • Hi sir,

    My comments are as follows:

    1. It is for sure that it is not in CBL because I have written CBL with a dynamic IP(Developed a middleware) for DSP which allows me to ping when device is in CBL mode. Ping responds for some time and after 5Sec, ping stops responding, which means device is out of CBL.

    2. Yes, both CBL and Application code separately calls InitSysCtrl() function in main at very first. The PLL locking is done there. 

    3. Yes, Using boot ROM SPI loader.

    Thanks in advance,

    Regards,

    RS

  • Rahul,

        Any update on this?

  • Hi Sir,

    Greetings...!!!

    Yes, Due to presence of capacitor in the hardware, system during reboot was not actually rebooting and when again a power off/on is given it works fine.

    Thank You,

    Regards,

    RS