Bootloader for MC9S12XDP512

cancel
Showing results for 
Search instead for 
Did you mean: 

Bootloader for MC9S12XDP512

2,557 Views
Forsaken
Contributor III

Hello, I have searched for bootloader in the last 3 weeks, but only find suggestions (pdf about LRAE and LFAE that contains a lot of theory and no practice) and posts of someone who knows someone who has a bootloader but never any code.
So I decided to write source code from scratch in which I ask every community to contribute to something so that there can be a source that we can all use.

 

I have wrote the bootloader code on Start12.txt file attached. I have placed bootloader code before the _Startup function, in order to be compiled and be programmed on ROM_C000.

 

 Even prior to calling the main function on _Startup function, I have place the call of Bootloader function.

 

 In summary, before starting the main program starts the bootloader where its function is to verify the existence of any attempt to communicate through the serial port in order to reprogram the flash, eeprom or until the ram, being the last one unnecessary on my mind. The transmission to be carried out through the serial data transmission is a file s19, probably the same as generated by the CodeWarrior with the code section on the ROM_C000 extracted.

 

When the transmission is completed, the bootloader function exits calling main function next.

 

So far, the state machine of serial port transmission is working fine, I have tested without the eeprom, flash or ram program rotines. When I introduce the program rotines, on the first write on flash (0xE08800 address for example) the microprocessor resets. I don't know why it does that.

 


Can any one help?

Labels (1)
0 Kudos
8 Replies

256 Views
mculater
Contributor III

Apparently you didn't come across the Serial Monitor/Bootloader we did for S12XDP512, announced on this forum a few months ago.  It is an adaptation of the Freescale AN2548 Serial Monitor, and fits in 2K of flash.  The source files are here:

http://support.technologicalarts.ca/docs/Adapt9S12X/Code/SerialMonitor/

We also did a Windows front-end, called uBug12x, which you can find here:

http://support.technologicalarts.ca/docs/Adapt9S12X/Code/uBug12x/

The uBug12x manual is here:

http://www.technologicalarts.ca/shop/documentation/63-debugging-tools/132-ubug12x-user-manual.html

 

Best regards,

Carl Barnes

www.TechnologicalArts.com

Modular HC11/HC12/S12/S12X Hardware

Evaluate * Educate * Embed

 

0 Kudos

256 Views
kef
Specialist I

Flash memory (whole flash or flash bank) is not readable while any flash command is in progress. Also not readable while you are applying backdoor unsecure key (KEYACC bit is set). Not readable flash means CPU can't read and execute code from flash. You should move and execute relevant code to RAM, EEPROM, or external memory.

0 Kudos

256 Views
Forsaken
Contributor III
OK. But when the bootloader is running, this code is running on the section from the ROM_C000 and not the flash pages designated to run the program. Correct me if I'm wrong.
0 Kudos

256 Views
kef
Specialist I

Yes, 7FC000'G and 780000'G probably are different flash banks and your flash routines may work from flash.

I see that in BootLoaderMachine() pAddress variable is never set to value other than NULL, you use NULL as a target flash address. Not sure why MCU resets in your case, but this is a serious problem and should be fixed.

Also, you case constants like 0xE08000 to far data pointer. For S12X CPUs, compiler threats these constants not as logical (banked) addresses, but as global addresses. You should convert these constants to global addresses.

 

void BootLoaderProgramFlashSector(UINT8* far pFLASHAddress, UINT8* far pRAMAddress)
{
  UINT8       i=0;
  UINT16* far pFLASHPointer=(UINT16*)pFLASHAddress;

^^ this is not right. You let compiler convert global address in pFLASHAddress to near address first, then convert that back to global address and store it in pFLASHPointer. Disassemble looks like this:

 

   25:    UINT16* far pFLASHPointer=(UINT16*)pFLASHAddress;
  0006 ee8e         [3]     LDX   14,SP
  0008 e68d         [3]     LDAB  13,SP
  000a 160000       [4]     JSR   _CONV_GLOBAL_TO_NEAR
  000d 160000       [4]     JSR   _CONV_NEAR_TO_GLOBAL
  0010 6e87         [2]     STX   7,SP
  0012 6b86         [2]     STAB  6,SP

0 Kudos

256 Views
Forsaken
Contributor III

Before all, I want to thank you kef for your the contribution on this matter.

Yes, you're right it about pAddress variable, I have fixed on my source code. As soon as the bootloader works i will post here a new attachment with the source code for everyone who wants it.

 

 

void BootLoaderProgramFlashSector(UINT8* far pFLASHAddress, UINT8* far pRAMAddress){  UINT8       i=0;  UINT16* far pFLASHPointer=(UINT16*)pFLASHAddress;

 I don't have experience with far and near declarations. What you suggest? Something like this (without far delcaration)?

 

void BootLoaderProgramFlashSector(UINT8* pFLASHAddress, UINT8* far pRAMAddress){  UINT8       i=0;  UINT16* pFLASHPointer=(UINT16*)pFLASHAddress;

 Meanwhile how did you dissamble the code? Did you use some external tool? Or it's a CodeWarrior option?

 

 

 

0 Kudos

256 Views
kef
Specialist I

  UINT16* far pFLASHPointer=(UINT16* far)pFLASHAddress;

 

To disassemble your code use context sensitive menu. In code editor window click right mouse button, then Disassemble.

0 Kudos

256 Views
Forsaken
Contributor III

Hello, sorry for my delay (Hollidays Vacations).

 

I have experimented with your suggestion, and did not work either...

The micro reboots when trying to flash the first information received. I will try now to have some information by debugging step by step.

0 Kudos

256 Views
kef
Specialist I

You should determine the cause of reset. CRGFLG and CRGINT registers, in particukar the state of PORF, LVRF and ILAF bits could tell you was it power on reset, low voltage reset or illegal address reset.

Pointing main, COP and CME vectors to different routines could tell you also was it COP timeout, CME failure, or no.

0 Kudos