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.

TI bootloader stall

Other Parts Discussed in Thread: OMAP-L138

Hi there,

I am working on a programm for the ARM side of the OMAP-l138.

My code lies in the SPI flash. On startup, the TI bootloader copies it to shared RAM (omitting the first 16 kB) and jumps to the entry point (_c_int00). So far so good.

From time to time my program needs to reboot, that is, to load the whole code from SPI flash to shared RAM and start at _c_int00 again, but without corrupting certain variables in shared RAM. Since I couldn't find a clue how to do this in the documentation I went assembler and set the PC to the start of the TI bootloader code (0xFFFD0000). That worked, too, and the TI bootloader reloaded my code as expected.

Recently, I had to move my code from shared RAM to the DDR2. Both .cmd file and AISgen settings were quickly adjusted, and the program worked. However, and now we finally reach my problem, the reboot described above doesn't work anymore. The TI bootloader starts, but at address 0xFFFD3010 to 0xFFFD3020 it runs in an infinite loop.

What the bootloader does in the loop is polling the (cleared) SYSCFG1->VTPIO_CTL->READY bit. This had been set when the bootloader startet, but somewhere it must have been changed (I didn't step through the whole code, so I can't say where or why).

 My question: What must I do to use a reboot as described above again? I don't insist on the 'set PC to 0xFFFD0000' method, if there is an other reasonable way to do this I would be grateful to hear about it.

  • Bjorn,

    There are various ways to warm reset the device via software, but I'm not sure they will guarantee memory contents will be preserved. Is that still a requirement?

    Regards, Daniel

  • Hi Daniel,

    thanks for the quick reply.

     

    Daniel Allred said:

    There are various ways to warm reset the device via software, but I'm not sure they will guarantee memory contents will be preserved. Is that still a requirement?

    It would be nice, but if necessary, I could copy the critical data to SPI flash before the reboot and check them there afterwards. This should happen quite rarely, so the limited flash rewrite cycles shouldn't be a problem; still, if possible I would use the shared RAM.

    Which solutions can you offer me?

     

    Regards, Björn

     

  • Bjorn,

    Probably the easiest way to effect a warm reset (equivalent to a pin generated warm reset) is to use the RSCTRL register of the PLLC0 (see section 8.3.4 of the System Reference Guide). You could also use a watchdog timer, but that would involve more setup.

    According to the design documents, internal memory contents would be preserved, but I would definitely recommend testing that before finalizing any software design.

    Regards, Daniel

  • Hi Daniel,

    RSCTRL works fine, and so far every time I tried it the shared RAM kept the values. Goot thing that register finally found it's way to the documentation.

    Thanks for the help.

     

    Regards,

      Björn

  • Bjorn,

    Thank you for testing and confirming that the memory contents are preserved.

    Regards, Daniel