Bootloader for MC9S08

[leesp]

I am reading a source code for MC9S08 part of which is supposed to respond to a USB bootloading command (the USB wants to flash new code into the microcontroller). When the MC9S08 is in normal user mode, and if it receives a command Cmd_BootloaderEnable from USB port, it is suppose to go into bootloader mode. The program goes like this (if I read the codes correctly):

1. Upon receiving the command from USB, the MC9S08 will set a variable flag BootloaderEnabled = '1'.

2. It then execute BGND command

3. Since the ENBDM is '0', the instruction BGND is considered illegal and SRS.ILOP will be set to '1'

4. MC9S08 reset

5. On start up, it checks whether BootloaderEnabled == '1', if yes, it jumps to bootloader code

6. USB starts sending bootloading command

Does my intepretation make sense?

- What is the pre-requisite for running bootloader (in order to flash new code to the microcontroller)? Does it have to be in active background mode?

- if ENBDM == '0' and BGND is executed, will the microcontroller reset and then go into active background mode? Or it will just do a NOP? If it does reset, the variable flag BootloaderEnable will be lost, right?

[kef]

Your interpretation makes sense. Uing BGND instruction to cause ILOP reset makes sense. Debuggers usually use active background mode and BGND will work as a breakpoint while debugging.

On reset variables are'n lost physically, MCU isn't initializing RAM on reset. But ANSI C compiler startup routine initializes all static variables at startup. In Codewarrior to prevent initialization of variable, you should allocate BootloaderEnabled in NO_INIT segment instead of READ_WRITE (see prm file and CW documentation).

• Does the MC9S08 have to be in active background mode in order to do self-programming?

No. Anyway you can't enter active background mode without debugger connected.

[leesp]

Dear kef,

Thanks for your reply. But I have some questions:

- Since MC9S08 does not need to be in active background mode in order to do self-programming, then why would the code execute BGND command to reset itself?

- You mentioned that one can't enter active background mode without debugger connected. But we just saw that the MCU itself can carry out BGND to put itself into active background mode, without debugger connected.

Pardon me as I am just a novice and I am confused..

[kef · Accepted solution]

Reset is useful because it's the only right way to reset everything to default state (except reset source bits like ILAF, PORF etc). You may try to reset all registers by hand, but this is error prone, difficult, and doesn't work with write-once registers and bits. And you need to reset if not everything, then at least disable all interrupts that application is enabling. If you reset registers by hand, then either your code is bigger than required (reset all registers or all interrupt enable bits), or it won't work after you some additional interrupt in application. Hardware reset is way more simpler and effective.

BGND works as "enter active backround mode" only if background mode is enabled using debugger. Also I wonder how did you detect than MCU entered active BDM because of BGND instruction?

Try making simple application which just makes LED on or pulses some pin on/off in a loop with BGND instruction. Is it working when powered on with debugger not connected? If yes, then either BGND behaves as NOP or reset. If not, then BGND makes MCU entering active BDM and waiting for instructions from debugger via BDM pin.

Regarding the only . It is not required to bootload soon after reset. Flash is always programmable, unless you write protect it.

[leesp]

Thanks kef, now I am clearer. I will just summarize here:

1. Reset is to make sure that the bootloader code can run without being interrrupted -  to make sure that it is the only program running, otherwise the flash program memory will all be messed up

2. Yes with BGND the processor will only go into active background if ENBDM = '1'. If ENBDM = '0' the processor will reset (I also read somewhere that it will just treat it as a NOP. But nevermind..)

3. User code can program the Flash anytime, but it only make sense to program it after reset, for the reason mentioned in 1.

Thanks!!

[kef]

• 1. Reset is to make sure that the bootloader code can run without being interrrupted -  to make sure that it is the only program running, otherwise the flash program memory will all be messed up

Not only. To reset write-once bits and write-once registers. On some MCU's flash protection register is writeable towards protecting more memory, while unprotecting is not possible. Reset helps.

• 2. Yes with BGND the processor will only go into active background if ENBDM = '1'. If ENBDM = '0' the processor will reset (I also read somewhere that it will just treat it as a NOP. But nevermind..)

 S12(X) family in normal modes have BGND behaving like a multicycle NOP. It can be inserted here and there if one wants fixed address breakpoints while debugging. Recompile for production mode is not required.

• 3. User code can program the Flash anytime, but it only make sense to program it after reset, for the reason mentioned in

I prefer reset to enter bootloader from application, but there may be special application requirements. What if there's a need for continuous PWM output, even while reflashing application...

[bigmac]

Hello,

---

kef wrote:

2. Yes with BGND the processor will only go into active background if ENBDM = '1'. If ENBDM = '0' the processor will reset (I also read somewhere that it will just treat it as a NOP. But nevermind..)

 S12(X) family in normal modes have BGND behaving like a multicycle NOP. It can be inserted here and there if one wants fixed address breakpoints while debugging. Recompile for production mode is not required.

---

For the 9S08 family, if ENBDM = 0, the BGND instruction will be treated as an illegal opcode, resulting in a reset condition.

Regards,

Mac

[kef]

Mac,

You are right of course. Leesp mentioned that he has read somewhere that BGND is threated as NOP when in normal mode. I guess it was about S12(X). S08 BGND causes ILOP reset when in normal mode.

Regards

[leesp]

Thanks mac & kef.

I understand now

[leesp]

In order for a microcontroller to do self-programming, does it have to be at "boot" time? I mean does the microcontroller have to load user program to its program memory only during boot time?

Can the microcontroller do this anytime, as long as, say, a button is pressed and the host PC is notified? Can I write a microcontroller code which will poll a pin regularly and check if it is pulled low. If the pin is pulled low, it will go into a subroutine which will listen to read/write command from a host PC, and execute the self-programming accordingly. Then it will be called "anytime-loader" right? Can this be done?

[leesp]

Does the MC9S08 have to be in active background mode in order to do self-programming?