Due to the U.S. Thanksgiving holiday, please expect delayed responses during the week of 11/22.

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.

TMS570LS3134: Jump to address 0x00000000 from application

Part Number: TMS570LS3134
Other Parts Discussed in Thread: HALCOGEN


I have a bootloader situated at the address 0x00000000.

My application is starting from 0x00008000.

I want to jump from my application to the bootloader resetVector. I don't want to use the warm reset (system reset) because I need to keep the output GIO at the same state when the application decides to jump to bootloader.

I tried this:

void (*pBootloaderResetHandler)(void);

pBootloaderResetHandler = (void(*)(void))(0x00000000);
/* start the bootloader program */

but it always falls in _prefetch. 

Is it possible to disable prefetch and program flow prediction?

Is it possible to jump to the bootloader without changing the state of GIO?

Thanks for your help

  • Hello,

    It is impossible to disable the prefetch abort. An error on an instruction fetch (or rather prefetch) causes a prefetch abort if that instruction actually gets to the "execute" phase. The Cortex-R4F features a speculative fetch wherein it tries to maximize the instruction fetch bandwidth by prefetching from the program memory space. Not all these prefetches are used and do not cause an abort even if some of the prefetches may cause an error.

    Most applications use the main flash memory as the program memory and the TCM RAM as data memory. In this case, a prefetch abort can only be expected when the CPU tries to fetch an instruction from a flash location that is either not valid (past the available flash memory) or which returns an ECC code that indicates a 2-bit error. You could also use the MPU to define some valid flash region as non-executable memory. A prefetch from such a region will also cause a prefetch abort.

    Can you tell us the reason that you don't use the CPU reset to switch to bootloader and the reason that you want keep the GIO status?
  • Hello,

    The power supplied of the computer used to update the firmware is controlled by a GIO situated on the board to update. If I use the System Reset, the GIO state is reset and the computer loses power during the transition.

    I need to keep the GIO pin ON during the jump to bootloader.

    The bootloader is situated in FLASH and is start VECTOR address is 0x00000000.

    My application is situated in FLASH and is start VECTOR adrress is 0x00008000.

    I use the standard Halcogen project to configure the uC at startup.

    Do you have a concrete solution to keep the GIO state and start the bootloader?

    Thank you for your time.

  • Hello John,

    There is no problem to jump back to bootloader from application using:

    pBootloaderResetHandler = (void(*)(void))(0x00000000);
  • John,

    You said you already tried this approach. You can also try resetting just the CPU and not the rest of the part. This way, you will branch back to 0x00000000, switch to supervisor mode (thereby avoiding the prefetch abort entries) and also keep any GPIOs states as configured prior to resetting the CPU. You can reset just the CPU by wriring to the CPU Reset Control register.

    Note that any CPU initialization steps are still required in the reset handler.

  • Hello John,

    The periphInit() which is called in systemInit() is to power up the clock to the corresponding peripheral. The peripheral select of the GIO module is 16.

    You can add a variable to record the boot cause. If the boot is from application (not reset), the bootloader ignores the periphInit() and the GIO state won't be changed.
  • Sunil,

    Just to be sure I'm doing the right thing, I use systemREG1->SYSECR = (0x10) << 14; for systems reset.
    What is the difference with a CPU reset?
    What is the procedure to generate a CPU reset?

  • Joel,

    A system reset will reset each IP including the GIO module, so that all GIO registers configured by the application will return back to their reset state. A CPU reset only resets the CPU leaving the other IP as configured by the application. The CPU reset still causes the next instruction to be fetched from 0x00000000 (reset vector) so that the reset handler needs to identify the cause of reset as a CPU-only reset, and then proceed to configure the CPU as required, and then execute the bootloader code you want. The GIO state will be maintained through this period.