MC9S12XEP100 in EVB9S12XEP100: bootloader and firmware: separating RAM spaces

[Rhapsody]

Dear All,

I'm coding a bootloader for the mentioned microprocessor. The bootloader is able to communicate with the SCI0 interface, to get a s19 file, save it in flash and starting the firmware. That's all working.

The only problem is that the bootloader and the firmware share the same RAM area, so problems arise when the SCI0 ISR buffers, that is handled by the bootloader, become dirty because of the firmware activity.

So I decided to dedicate a RAM area of 2k to the bootloader within the non paged ram, and the rest for the firmware, using the first 256 byte of the non paged ram for the stack, that is in common to bootloader and firmare.

So, the memory layout is:

0x2000 to 0x20FF -> common STACK

0x2100 to 0x37FF -> DEFAULT_RAM for firmware 

0x3800 to 0x3FFF -> DEFAULT_RAM for bootloader

0xC000 to 0xFEFF -> FLASH for bootloader

0x4000 to 0x7FFF -> FLASH for firmware

The first bytes of the flash of the firmware are reserved for the address of the main routine of the firmware itself and for the addresses of other functions provided by the firmware that have to be called by the ISR that resides within the bootloader, since I left all the interrupts handling functions within the bootloader.

Everything is working: when I upload and start the firmware, the main of the firmware is called. When, from the serial console I type the command '!b' (that is a command of mine to break the execution of the firmware) the SCI0 routine changes the return address on the stack so the RTI gives the control back to the bootloader.

The problem that now I have is that when I separate the RAM areas to avoid overlapping of buffers, the firmware routines seem not to work. I mean, my firmware is intended for the moment to respond only to the PIT interrupt and to the SCI0 requests (through the bootloader ISRs) and should greets with an SCI0 message, but it doesn't. 

When I overlap bootloader and firmware RAM areas, everything is OK (except for the overwriting issue). Infact, if I use the same DEFAULT_RAM, to say, at 0x2100 to 0x3fff, everything is ok.

I went through the assemply code and the routines for writing to the serial interface are correctly executed, but nothing comes to the terminal.. they correctly write to the SCI0DR but nothing comes up to the screen.

Someone can tell me where are my mistakens?

Again, if you have suggestions about my idea of bootloader, since it is the first time I write one, they are very welcome..

Thanks in advance,

Ale 

Message Edited by Rhapsody on 2009-05-29 11:33 AM

[Rhapsody · Accepted solution]

Really sorry to have bothered you, I've solved the problem by myself, and it was very trivial. When the areas were overlapped, the firmware global variables went initialized to zero by the init routine of the bootloader. Separating them, the firmware global vars were not initialized anymore, and so the faulty behaviour.

Anyway, if you have suggestions about my bootloader, please write

Thanks,

ale 

[jsmcortina]

Why do the overlapping RAM areas matter? Isn't a bootloader, by definition, only run once at boot?

James

[Rhapsody]

Yes, but maybe I've named that piece of software the wrong way. Actually, its purpose is to hijack the serial communications, parse them, and then pass the commands related to the firmware, to the firmware itself, and take the control when it is invoked using its own commands. To achieve this, I have used some dedicated ram for doing the parsing work. Again, this software is the only one that will have access to the hardare, so the firmware has to invoke it, for example, for sending something to the serial module, or for changing the port bits. Actually is more like a very basic and simple kernel, than a bootloader. In addiction, it has to be able to substitute the firmware with a new one passed using the serial interface.

Ale