what is the boot sequence on 52259?

[Leong]

Hi, I'm trying to write a custom bootloader for a 52259 custom board. I'm a bit confused about the example code provided as usb bootloader. It came down to the basic question: what is the boot sequence (first instruction) of the processor after reset? If it boots from flash, what is the first instruction it loads? The example zip file has a subfolder called "bootloader with application", in its lcf, it defines the lower 0x418 bytes in the flash as vectorrom. in the other "standalone application" folder it defines the same vectorrom as well. But the two projects have different entry definitions in their own 5225x_vectors.s. If the bootloader receives the "standalone" file and burn it to flash, isn't it going to override the vectorrom? 

and my confusion over this "bootloader with application" concept. If I just need a bootloader, i don't want it to be a library or part of the application. is that case not shown by the bootloader example? 

[grilialex]

I have written a bootloader for 52254 myself on a custom board.

I have two separate projects.

The bootloader, has at 0x0000_0000 (Flash) its vector table and contains the CFM_prot area for protection flags of flash memory. The bootloader recognize a special configuration area where the vector entry points are stored (downloaded with the code). So the bootloader after its sanity checks jump to the application entry point. This entry point is the reset vector (stored in flash) of the application.

The application starts at a different address, say 0x0002_0000. First section is the vector table. The reset vector (0x0002_0000) point of the actual code. Now the first part of my code after the hardware initialization (PE) but before interrupts are enabled (I must delete the EI() command in PE exit) has a small code to copy the Flash vectors from 0x0002_0000 to RAM, where the VBR can point. It sets the VBR and the enables the IRQs. Then execution continues normally.

Keep in mind if you configure properly the BDM tasks you don't need to erase the whole chip. In bootloader application i erase and program only the interested areas (bootloader code), while in application i erase/program only the application code. Thus when i debug the application the bootloader is intact and vice versa. The only thing is that if i download the application with BDM the checks fail so a power-up sequence will stay in bootloader mode (as it should). I have to download the application normally to have it start up correctly, but this is an expected behavior.

I did not play with the linker files manually for this case (only when i made a special application for bootloader update!).

Hope this helps.

Ilias 

[Leong]

I might have an answer to myself ..

ColdFire V2—Register CFMPROT is set to 0x1 and protects the flash address range 0x0 to
0x3FFF. This register is set in file mcf5225x_vectors.s

i guess though the application S19 contains this section but the bootloader is not actually changing it.

but this brings another question: if i use bdm to flash the same application code, isn't the bootloader vector table going to be replaced by the application vectorrom definition? can i just not to define this vectorrom in my application code but to generate only the vectorram?

[Mudwog]

Leong,

I have written many bootloaders.  The application exec must be coded to accomodate the interrupt vector strategy implimented in the bootloader.  There are a number of variations for bootloader interrupt vector schemes.  Burning a "stand alone exec" with the BDM device will always wipe out the bootloader, as far as I can tell.

The bootloaders I've written can usually boot from two (or three) different sources, so I usually write the bootloader to run with its vectors in RAM, and I write my "bootable exec" to have an interrupt jump table at a fixed address in FLASH.  During normal operation of the exec the interrupt vectors in the protected boot sector of FLASH point to the jump instructions in the exec's fixed location interrupt jump table.  Except that the reset vector goes to the bootloader which decides based on some other signal if it should run the exec or the bootloader.

I recently modified the USB bootloader for my own use I've attached the vector module that I wrote for my version of the bootloader.  The fixed location of the interrupt jump table is defined in the .ld file for the bootable exec and cannot change without changing the bootloader.

I hope this helps.

Mudwog

[Leong]

by the way. I noticed that your executable starts at 8k+. the data manual says that if CMFPROT is on, the lower 16K flash would be unwritable so that the bootloader can protect itself.

Regards

leong

 * INTERRUPT_JUMPS:        0x2000 * EXEC_FLASH:             0x2600         the executable code start

[Leong]

Thank you both for the reply.

Eventually I was able to separate the boot code and the application code, similar to the approach Mudwog describs. Since I need the bootloader to be versatile, so I have the lower 0x400 bytes as bootvector and it's defined by the bootloader usage alone. I also claimed another 0x400 byts at 0x0000_4008 for the applciation vector table. Byte 0x4000 to 0x4008 are used to hardcode a "jmp app_entry" instruction in the bootloader code which is called when bootloader is skipped. By doing it this way the application boot vector lower 2 slots are actually not used, since the program does not start from there. The init code in the application has to clear out all rams and reinit stack register (pc is correct at this point), reset data ram and copy the ramvector from the 0x4008 location. 

The second approach described by FridgeFreezer is similar to how the demo usb bootloader+application is done. Thus the vector table is shared (lower 2 slots by the bootloader, rest by the application). One problem for me is that with this approach the code size exceeds the linker allowance. And it is tricky to get the version control.

[FridgeFreezer]

I think I see what you're asking, I am not very experienced but I will tell you what we have done that works well in our product;

We write & compile a bootloader as a .bin executable, this lives in the bottom of the flash memory. Then in our main project we include the bootloader.bin file in a reserved section of the .lcf

That gets around several problems;

1) The bootloader is always exactly the same (if you just include the same source code it will compile differently and cause problems like different checksums etc.)

2) The binary executable gets written directly to the correct place by the BDM pod

3) The main project is built "around" the bootloader.bin at compile time, so it's not being relocated or over-written etc. by the bootloader.

4) The main project has no visibility of what's inside the bootloader.bin, but you can start & run either from 0x0000 or from main() with the BDM debug and step through.

If you search back through some of my posts you'll find examples of how to make this work.