A boot loader for 9S12X

[jcdammeyer]

I need some help developing a boot loader for a 9S12XDP512 and none of the app notes out there address the 9S12X series which appears to have different Flash.  Also I need to boot from an image stored in an unused part of the 9S12X flash.  (I have 512K total).  I've written code to receive an .phy file and store the text in unused pages in the flash memory.  That's with the structures below for file name and size information.  That same flash area is also used to hold update code for PIC series modules and will be sent over CANOpen to those devices.  So the 9S12X is the gateway for upgrading all the modules on a CANOpen network.  Eventually this 9S12 may have an add on SD card on some versions.  That's why the 'file' oriented format for saving code upgrades.

The file 24 pointers now work for writing and reading flash but my next problem is setting up a bootloader.  The 9S12X has the IVBR so theoretically I can code the boot loader to use the standard default upper vectors and then if the application code image is healthy map the user's interrupt vector base into the IVBR and jump to the user start location.

Where I'm having trouble is how to set up the PRM files for the Bootloader and the application.  The bootloader just has to start up, verify that the code image is correct and that a location in EEROM doesn't say install new code.  If the EEROM location says install new code it verifies that the image in flash is for the right processor and that it's intact.  Then just read the phy file line by line and program flash.  If it suceeds, jump to the application.  If not flash some LEDs.

Can anyone give me some guidance on setting up the .prm?

Thanks

John Dammeyer

/*

    The Code Control Block holds all the information required for the

    9S12 or dsPIC or PIC boot loaders.

*/

#define CONTROL_BLOCK_SIZE      16  // 16 words 32 bytes.

typedef union _codecontrolblock {

  struct {

    ULONG Id;          // Holds 0xFEEDCODE

    WORD CRC;          // Block CRC

    char FileName[9];  // general format name is xIMn_ssv

    char Suffix[4];    // .phy, .hex, .bin

    char Format;       // 'S' (Motorola) or 'I' HEX (Intel) format or 'B' BIN

    char TargetID;     // CANOpen NodeID of destination. (1 == ourselves)

    char Open;         // Ram Structure holds 1 if file open, 0 if closed.   

    WORD Size;         // Size in WORDs.

    WORD WritePosition;

  } f;

  unsigned int a[CONTROL_BLOCK_SIZE];

} TCODE_CONTROL_BLOCK;

typedef struct _codeblock {

    TCODE_CONTROL_BLOCK CodeInfo;

    WORD CodeImage[1]; //[1] to be able to set a pointer.

} TCODE_BLOCK;

[lama]

Hi,

probably it would be good to direct you to existing bootloaders created in CodeWarrior.

S12XDP512 - see attached files

If you want to read more info how it works you can read

http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4258.pdf

which is however designed for another S12 MCU family with different apprach to program the flash but communication approach is similar to XDP512 device.

Best regards,

Ladislav

[jcdammeyer]

Thank you for your reply.  I ended up starting with the AN4258 application note and modifying it for the 9S12XDP512.  A lot of work but it's finally working. 

Since I'm working with the P&E tools for debugging I've used their Log2Phy program because the SRecCvt.exe that came with the AN4258 app node code doesn't run on my WIN7 system.  However, the version in the zip file you provided does so I may switch over to that. 

One of the many little issues early on with the boot loader was the Log2Phy program created one record with 9 bytes rather than an even number.  9/2=4 and writing 4 words leaving off one byte caused a lot of head scratching.  I hadn't realized there was an odd number until I single stepped through the assembler code.

My hardware doesn't have any kind of jumper or I/O position available for automatically selecting the boot loader on power up.  Instead I use CAN0 and CAN4.  The end user can jumper between the two CAN bus channels and a dominant/recessive/dominant on the bus for a few hundred milliseconds serves as a clear indication that the boot loader should start up instead of vectoring to 0xC000.

And my serial port is actually parallel through an FTDI245 USB interface.  Unfortunately if the 9S12X hangs then sometimes so does the USB.  Every once in a while that results in device driver thinking it's found a serial mouse which then causes no end of grief on a Windows system.

My system needs to be upgraded remotely so I also need to be able to start the boot loader without it immediately hopping back into the application.  To make that happen I moved an erase sector function down into RAM can called it to erase the sector that holds the 0xC000 address.  Then I cause a COP event that resets the processor and this time the boot loader doesn't find the 0xC000 and stays waiting for a new code image download over the FTDI245 port.

I suppose I could also call an alternate entry point for the boot loader that doesn't test either the CAN port pins or look at the boot address.  But if the erasing flash fails before the boot address sector is cleared then I'm left with a valid boot address but invalid code.  Perhaps the page and sector erase should work backwards first erasing the highest page.  But the COP method resets everything which is probably safer.

Comments are welcome.

Thanks

John