How to enter Bootloading Mode?

[sebasira]

Hello everybody!

I'm working with CW4.6 and both HCS12A128 and HCS12A256. The project was started with 128 and then because we have stock of 256 MCU's we decided to use them.

My doubt is how can the firmware enter bootloader (bootloading?) mode itself? I mean, normally bootloader is entered by an external action like a switch, but what I want is to send a string via SCI and so the program enters bootlaoder anytime I want it to. This said, my first thought was to JUMP to bootloader address (in my case 0xF0C0) when the string arrives but I don't know how the MCU will behave, or if there would be a problem with other registers configuration (remember the code was in normal execution before entering bootloading mode).

Then I thought on writing EEPROM and reseting the equipment. Then the bootloder will read this EEPROM address and if it founds an special code, enters bootloading mode. This was working great with 128 but it hangs with 256.

The problem with the 256 MCU is kind of rare... Let's assume I download the code via BDM and left it connected to the board. If I send this special string via SCI, the EEPROM is written and if I hit the reset button on HiWave and then RUN again the code, it works fine and enters BOOTLOADING MODE. But if I reset the MCU by a switch connected to RESET line instead of hitting HiWave button, then when it startup again, it hagns and I don't have a clue about why's that and I cannot debug it because if I debug it, it works ok. (The only thing I know is that this problem is related to INITRM register because the main firmware has a value for it, the bootloader another one; and if I don't touch this it runs ok but cannot enter bootloader)

Do you know about any other method for entering bootloaing mode?

Or if you think is safe to just JUMP to bootloader address, that's ok with me and work.

Thanks as always, I hope someone can help me out

SebaS

[kef]

It sounds like write once register issue. Isn't it? To debug it you may try placing for(;;) loop somewhere at reset vector and use debugger's hotplug mode (there must be a button in Hiwave connect dialog window).

Hotplug - to debug in normal mode, for(;;) to make target stopped at start of program. Of course for(;;)  may make compiler optimizing all the code below for(;;), so you'll need to use while(some_pin), for(;;) coded in asm or something like that.

[sebasira]

Well Kef, I did what I said before, and the problem is indeed a write-once register. Then I go back to datasheet and found:

"...registers INITRG, INITRM, and INITEE. During normal operating modes these registers can be written once..."

I can swear I look into the datasheet seeking this before posting and couldn't find it.

The big question would be... How can I overcome this?

I'll explain a bit more. The main program (first written for HCS12A128) has those values: INITRM = 0x00 and INITEE = 0x21. And in PRM:

RAM = READ_WRITE    0x0400 TO   0x1FFF;

PAGE_EEPROM   = READ_ONLY  0x2000 TO 0x27FF;

When the application receives a special sequence via SCI, in writtes a key value at addres 0x2004 (EEPROM) and then self-reset (for now, let's say it generates a pulse in RESET pin). Then, the bootloader would have to check for this value at address 0x2004. In order to do that, it hast to set INITRM and INITEE as the main app (0x00 and 0x21 respectively). And if it needs to enter bootloading mode, then it would have to change INITRM again to be 0x50 (that's the value the bootloader uses). The bootloader was not develop by me, it's from some AN of Freescale. If I don't change INITRM value, all I see at that address is a lot of 0xFF.

Any idea?

[kef]

"normally bootloader is entered by an external action like a switch"

Is this switch connected to read only pin? If not, then you may set data direction and port value as if switch was in bootloader position...

Do app and boot setup INITEE to different values? If so, then there should be no problem to set up INITRM after checking boot key in EEPROM.

You may also write boot pattern to RAM and look for it at different address according to new INITRM setting.

[sebasira]

Well Kef, I finally decided to change the memory map in my app so both the bootloader and the app uses INITRM = 0x50.... I didn't want to do that before because I thought it would be harder, but it was pretty easy! Now I always write the same value and there's no problem with write-once registers.

Thank you for pointing me in the right direction!

Best Regards!

SebaS

[RadekS]

The main problem is that EEPROM is always overlay by RAM/Registers until you change memory map (INITEE or INITRM).

Just idea: using RAM instead EEPROM.

RAM content stay unchanged until PORF flag is set.

We can test RAM in default position (prior we change INITRM).

Of course, area with flag (I would like to recommend some sentence, RAM content is random after reset) in RAM should not be initialized (NO_INIT) by init code (typically Start12.c).

This way we ensure that bootloader will be only called by application.

[sebasira]

Hi Radek!

Yes, that's one of the things I learn while dealing with this problem. I didn't know about it. If I had known it before, I would certainly use RAM instead of EEPROM.

Anyway, I would have to change the RAM allocation of my project (application) to match the bootloader or I would have the same problem with write-once INITRM.

Thanks!!

[kef]

In contrast to EEPROM, at least a part of RAM is available with reset default INITRM setting. This allows to check bootloader flag-pattern in RAM without write-once locking INITRM.

[sebasira]

Hi kef, I think you're right, and I haven't noticed that. I'll take that into account for the future

[sebasira]

Thanks for your reply.

About the switch, I was trying to say that normally in a generic bootloader the it enters booloading mode by an external actions. Thats not my case. This is a remote equipment and the idea is that it can enter bootloading mode without an external signal (except a remote package via RS232)

App and boot setup INITEE = 0x21. The difference is in INITRM, app set it to be 0x00 and boot 0x50.

I was doing some test... I found that for the HCS12A128, 0x2000 is EEPROM, but for the HCS12A256 it is RAM. They both sets INITRM = 0x00 and INITEE = 0x21.

The HCS12A256 has 12kRAM so it is mapped 0x0000-0x3000 with INITRM = 0x00 right?. I'll try placing EEPROM at 0x3000

[sebasira]

Hello Kef!

I'm sorry, I think don't understand what you want me to do...

This is what I understood. The code would be:

INITRM = 0x09;

INITRM = 0x50;

for(;;)

and then I disconnect BDM and reset the hardware, the plug the BDM (hotplug) and see if the value of INITRM is the last one. Am I rigth?

[kef]

No, it has nothing to do with connecting BDM plug.

INITRM register has write once protected bits. Write once protection works in Normal modes, but write once protection is disabled in the Special Single (SS) Chip mode, which is default operation mode for usual debugging. To debug write once issue, you need to debug in Normal Single (NS) chip mode instead of SS mode. To debug in NS mode, Hiwave debugger has somewhere Hotplug button. .... OK, I got debugger connected.... In Hiwave go to HC12Multilink->Communication... You should see there Hotsync button. When you hit it, debugger won't reset your MCU into SS mode, but instead just try to stop CPU. So you may reset MCU cycling power or pulling RESET low into NS mode, hit Hotsync button in debugger, and debugger will stop MCU where it is without changing operating mode to SS. But since you want to debug from top of program, you need to halt CPU somehow. For, while, asm " xx: bra xx" etc  can be used to make CPU looping at start of program. After Hotsync/hotplug you may modify PC address or set loop variable to continue debugging.

Some older Hiwave debugger had no Hotsync button, but there was an checkbox in Hiwave Setup window called like Hotplug (... target is running). It will work like Hotsync button, but you need to not forget to uncheck it later before flashing new firmware version using debugger.