Bootloader, CodeWarrior 5 and P&E Multilink.

[ItsADreDay]

Hi there!

I am using a MC9S12E128, CodeWarrior 5 and a P&E Multilink.
My board has code that runs great. So what i decided to do was to make a bootloader that would check a MMC slot for a card, and if card was found, update the code. Let me walk you thru my idea.

On the main code, i changed the vector table to be created at 0x7F80. Then before any interrupt was enabled, i would move my RAM to be from 0xE000 to 0xFFFF and then copy my vector table to 0xFF80. The main code would reside anywhere besides from 0xC000 to 0xE000.

On the bootloader code, i fit the whole code from 0xC000 to 0xE000. The vector table for this code is normal (at 0xFF80). This code would check the MMC card using SPI, read the S19 file for the updated main code(generated by CodeWarrior), and copy it to flash (using the code i found on the freescale website on AN2720). After that was done and working, the program would just jump to the reset vector of the main program (at 0x7FFE) which in its turn would tell the code to go to the beginning of the main code (at 0x4001). Also, if there is no card present, it would just assume that there is already a main code programmed and jump to its reset vector right away. The bootloader won't update itself.

I hope i explained it right, here is the issue:

When i compile the code using CodeWarrior, program it using the Multilink and tell it to run on the debugger screen, the program runs, sees the card, copy the main code to flash, jump to the main code reset vector and runs main code. If i reset the board using the on screen debugger, it works too. But after that, if i just turn the board on, it wont jump to the main code! So it works if i have the debugger on, it wont if i have it in stand alone. The bootloader works, it finds the reset vector, the reset vector is pointing to the right location for the beginning of main code (0x4001) but it wont run main program.

What am i doing wrong?

Thank you,

Andre

P.S.: Sorry for long message....

[J2MEJediMaster]

Are you ensuring that the watchdog register gets touched every so often? Or, conversely, have you disabled the COP? Lengthy operations will cause a COP reset unless you "feed the watchdog" every so often. The debugger usually disables the watchdog, which is why the program runs without trouble in the debugger.

Check this thread for more info.

---Tom

[ItsADreDay]

Tom,

Thank you for the prompt answer. The watchdog timer is disabled by the bean on the bootloader and enabled by the bean in the main program. That is something that i did not think of and will investigate further.

Playing with this thing some more, here is what i found out.
I loaded the code with the multilink and had the debuger window on. Then i power cycle the board (which makes the code start running but the debuger to lose track of it). Then i clicked on step and the debuger caught on with where the code was. It was on a bean generated code for the cpu inside an interrupt:

ISR(Cpu_Interrupt)
{
}

It was going there because that function is called for all the vectors in my vector table that are not being used. On further investigation i realized that the vector that is calling that function is on 0xFFF4 (XIRQ if I'm not mistaken). I figured since that was an external interrupt I would initialize that pin (PE0 or Pin 56) to a regular bit I/O so the interrupt wouldn't happen. Still it does not work.

Does that shine any light into this problem for anyone?

Thanks again,

Andre

[ItsADreDay · Accepted solution]

I found the bug!!!

The main code and the bootloader code had the ram set up in two different places. So after my bootloader got done and tried to jump to his code, his code would try to set the ram at a different place. Problem is that the register that does that can only be set once (and after the bootloader code set it at the beginning, the main code would try to do it again). To fix the problem I changed the position of my ram to the same place as the main code. That meant that I put the ram on top of my vector table, but since the bootloader does not need any interrupts, I should be fine. Easy fix!

Now, the datasheet also says that those registers can be modified more then once if the microcontroller is running in special mode, for example in DEBUG! So thats why the whole thing would work in debug but not afterwards...

Thanks for everyone that spent some time trying to figure this out. If you need more information about anything just reply to this thread.

Andre

P.S.: Hooray! Bootloader works!!!