AN2295 (HC08/S08 Developer's Serial Bootloader) updated for rev. 9.2 - CF V1 (alpha) support added

[ok2ucx]

Dears,

software for Application note AN2295 (HC08/S08 Developer's Serial Bootloader) has been updated recently. Since the last rev. 8 (Aug-2006) several additions and enhancements has been done:

• S08LC family added
• S08QE (Flexis) added
• S08GB/GT family updated for A-family
• S08EL/SL family added (including EEPROM programming)
• S08QD family added (with software SCI)
• S08DZ family added (including EEPROM programming)
• HC08GR8A corrected
• S08QG8 corrected
• hc08sprg.exe master updated
• simple Windows GUI application added
• all projects updated for CodeWarrior 6.1

HC08 families supported: AB/AS/AZ, AP, GP32, GR(A), GZ, JKJL, JKJL8, JW32, KX/EY/GT, LB, LJ, MR, QB, QC, QT/QY, SR

S08 families supported: AW, DZ, EL/SL, GB/GT(A), LC, QD, QE, QG, RC/RD/RE/RG, SR

Any comments, reports, suggestions or wishes are more than welcome. Some of the latest bootloaders are still in alpha stage, tested briefly.

Direct download link is here:
http://www.freescale.com/webapp/sps/download/license.jsp?colCode=AN2295SW

Unfortunately accompanying application note AN2295.pdf has not been updated yet (to reflect new protocol variations).

Best regards, Pavel, ok2ucx
Freescale Czech Republic
an2295 developer


Message Edited by ok2ucx on 2008-02-19 04:16 PM

Message Edited by ok2ucx on 2009-08-04 10:37 AM

[alzomor]

Hi

I am using LK24 Family

I am asking about flash protection is it possible while using the boot loader?

Thanks

Salam

Hossam Alzomor

www.i-g.org

[ok2ucx]

---

alzomor wrote:

Hi

I am using LK24 Family

I am asking about flash protection is it possible while using the boot loader?

Thanks

Salam

Hossam Alzomor

www.i-g.org

---

Hi,

the usage of Flash protection depends of the way how protection is implemented on the actual device.

A) Most HC08/S08's do have FLBPR implemented as Flash register that is being copied to run-time register during RESET event. FLBPR gets programmed along with the code. In this case bootloader code is the one that is programmed first, via BDM/MON08, somewhere near interrupt registers, around 0xFFC0 address, this depends on the actual device.

This feature is 'owned' by the bootloader to protect the bootloader. HC08LJ/LK24 are like these. See also AN2295.pdf for more information about this limitation.

B) Some devices do have FLBPR implemented as RAM-like register that is modifiable in run-time by the code. In this case, bootloader sets FLBPR to protect itself, but the user application can change this anytime and can erase/reprogram bootloader flash area then. HC08LJ12, HC08JW32 and few others are designed like that.

Pavel

[gabbo9lli]

Hi.

I transfer application on my DEMOACKIT for MC9S08AC128.
Then I try to communicate via COM port with microcontroller.

Application wait indefinitly in "Waiting for MCU reset ACK...".

Any suggest?

Thanks.

[ok2ucx]

This issue is typically caused by 'lazy' RS232 hardware - ie. ACK char from the MCU comes out before the RS232 is ready to send the data out toward PC - here or here. Adding a short delay before actual transmission typically helps.

You may double check with scope whether the ACK is really being transmitted - most implementations require Power On Reset. One checkpoint is at TXD pin of MCU, second at RS232 connector.

Pavel

Message Edited by ok2ucx on 2010-01-08 01:18 PM

[gabbo9lli]

Hi.

Now, master program receives char, but not 0xfc.

...

"Source address range: 0xFB6A-0xFFFF

Waiting for MCU reset ACK...received 0x00 (off-key).
Wrong calibrate response (0x00, must be 0xfc). Target is not calibrated."

Any suggest?

Thanks.

[gabbo9lli]

I compile PC Bootloader Master Software on Linux, using gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8).

I find this error:

prog.o: In function `check_image':
/media/DATA/working/cf3000/sw/freescale/an2295sw/master_linux/prog.c:950: undefined reference to `strnicmp'
collect2: ld returned 1 exit status

I substitute strnicmp with strncasecmp.

But I don't be able to upload firmware.

./hc08sprg /dev/ttyUSB0 project.s19
---------------------------------------------------------------------------
hc08sprg - Developer's HC/S08/CFV1 Serial Bootloader - $Version: 9.0.57.0$
---------------------------------------------------------------------------
FC protocol versions supported:
        0x01 (HC08)
        0x03 (large HC08)
        0x02 (S08)
        0x06 (long S08)
        0x0A (large S08)
        0x04 (ColdFire V1)
---------------------------------------------------------------------------

Parsed S-record lines: 25  Bytes total: 626
Source address range: 0xFB6A-0xFFFF

Waiting for MCU reset ACK...received 0x00 (off-key).
Calibration break pulse sent. Count: 11
Wrong calibrate response (0x00, must be 0xfc). Target is not calibrated

The same happens if I compile with mingw under Windows Vista.

 Any suggest?

 Thanks in advance.

[ok2ucx]

---

gabbo9lli wrote:
...

Waiting for MCU reset ACK...received 0x00 (off-key).
Calibration break pulse sent. Count: 11
Wrong calibrate response (0x00, must be 0xfc). Target is not calibrated

---

Hi,

I see both your tests (seems that Win & Linux version are tested). This typically happens when the RS232 hardware powers up and during this event keeps the TxD line low for certain period. PC RS232 receiver decodes that as 0x00 characted, which is (by definition) valid as ACK character transmitted 3 times slower than expected (ie. 9 bits low in a row).

Either look at the hardware or maybe some quick hack may possibly help in prog.c code:

//////////////////////////////////////////////////////////////
// wait for hc08 reset

// target send us ACK (0xfc) but in this time, it might be off-key up to factor 3
// so we might receive FF, FE, FC, F8, ..., 80, 0

static int could_be_ack(unsigned b)
{
 b |= 0xff00;
 while(!(b&1))
  b = b >> 1;

 return (b & 0xff) == 0xff ? 1 : 0;
}

modifying the code for:

static int could_be_ack(unsigned b)
{
 b |= 0x7f00;
 while(!(b&1))
  b = b >> 1;

 return (b & 0xff) == 0xff ? 1 : 0;
}

should remove testing ACK character for 0x00 value. This would effectively reduce possible tolerance for receiving ACK but it should be no issue for the most if not all existing implementations.

I may consider this as the 'official' improvement of the bootloader code.

Hope this helps.

Regards, Pavel

  

[gabbo9lli]

Hi.

I improve last message's code. My status doesn't change.

I attach my application board for HCS08AC128 at scopemeter in pin SCI1TX and SCI1RX.
After reset or after power-on of application board, I should see a 10 bit (1 start bit + 8 data bit+ 1 stop bit) signal ($FC) at 9600 bit/s.
So, signal should continue for 1.04 mseconds (104 useconds * 10).

In slfprg-s08ac128, signal continues for ca. 260 mseconds.

Maybe, does microcontroller send other char to SCI1 interface?
Should I change frequency of ICGOUT?

Other suggests?
Thanks.

[ok2ucx]

---

gabbo9lli wrote:
Hi.

I improve last message's code. My status doesn't change.

I attach my application board for HCS08AC128 at scopemeter in pin SCI1TX and SCI1RX.
After reset or after power-on of application board, I should see a 10 bit (1 start bit + 8 data bit+ 1 stop bit) signal ($FC) at 9600 bit/s.
So, signal should continue for 1.04 mseconds (104 useconds * 10).

In slfprg-s08ac128, signal continues for ca. 260 mseconds.

Maybe, does microcontroller send other char to SCI1 interface?
Should I change frequency of ICGOUT?

Other suggests?
Thanks.

---

260μs pulse shall be OK. 0xFC ACK is a sequence 0 00111111 1 (0 for start bit, 00111111 for 0xFC, LSB first, followed by stop bit) - so actually three zeros (not ten). That means that ACK should be seen as 3*104μs (1 bit @ 9600Bd), +-25% due to ICG inaccuracy.

If you see 260μs pulse on MCU TxD output that's perfect, but you should be seeing it also at RS232 levels (~+12V/-12V = on the COM port connector). And this may not be happening in your application, as possibly the RS232 lever shifter is not fully powered up (charge pumps charged properly) at the time when MCU sends out 0xFC character. That's what I call 'lazy RS232 interface'.

Either delaying the 0xFC transmission or modifying RS232 hardware typically helps.

Pavel

Message Edited by ok2ucx on 2010-01-14 05:09 PM

[gabbo9lli]

Hi.

Now I don't be able to erase memory. This is my actual situation.

---------------------------------------------------------------------------
hc08sprg - Developer's HC/S08/CFV1 Serial Bootloader - $Version: 9.0.57.0$
---------------------------------------------------------------------------
FC protocol versions supported:
        0x01 (HC08)
        0x03 (large HC08)
        0x02 (S08)
        0x06 (long S08)
        0x0A (large S08)
        0x04 (ColdFire V1)
---------------------------------------------------------------------------

Parsed S-record lines: 169  Bytes total: 5286
Source address range: 0x20F0-0xFFFF

Waiting for MCU reset ACK...received 0xfc (good).

Bootloader protocol version: 0x0A (large S08, read command supported)
Bootloader version string: AC128
System device ID: 0x01B [MC9S08AC(96/128)] rev. 0
Number of memory blocks: 6
Memory block #1: 0x0020F0-0x00FB69
Memory block #2: 0x020000-0x027FFF
Memory block #3: 0x040000-0x04BFFF
Memory block #4: 0x050000-0x057FFF
Memory block #5: 0x060000-0x06BFFF
Memory block #6: 0x070000-0x077FFF
Erase block size: 512 bytes
Write block size:   0 bytes
Original vector table: 0xFF9C
Bootloader user table: 0xFB6A

Are you sure to program part? [y/N]: Y
Memory programming: E 0x0020F0 0%

Any suggests?

Thanks.

[ok2ucx]

Hmmmm,

this looks like there are some communication issues, the characters (values) are received incorrectly. Probably the speed is mismatched, can you check by scope? 9600Bd = 104us/bit. +/-3% should be OK.

First, there's no calibration seen, or at least I do not see the following line in your log:

Calibration break pulse sent. Count: 1

Does calibration occur?

Then, there are wrong addresses and write block size. If in doubt, try Debug version hc08sprg.exe and look for communication data that are being received by the PC. The following values should be seen during reception of IDENT command:

8A         [FC protocol version]001B       [SDID]06         [number of Flash blocks]0020F0     [Flash block #1]00FB6A028000     [Flash block #2]02C000048000     [Flash block #3]04C000058000     [Flash block #4]05C000068000     [Flash block #5]06C000078000     [Flash block #6]07C000FB6A       [Bootloader user table address]FF9C       [Original vector table start]0200       [Erase page size]0080       [Write page size]<text>,0   [AC128 text]

Pavel, ok2ucx

[gabbo9lli]

Hi.

Here's debug version:

--------------------------------------------------------------------------
hc08sprg - Developer's HC/S08/CFV1 Serial Bootloader - $Version: 9.0.57.0$
--------------------------------------------------------------------------
FC protocol versions supported:
        0x01 (HC08)
        0x03 (large HC08)
        0x02 (S08)
        0x06 (long S08)
        0x0A (large S08)
        0x04 (ColdFire V1)
--------------------------------------------------------------------------

Parsed S-record lines: 169  Bytes total: 5286
Source address range: 0x20F0-0xFFFF

Waiting for MCU reset ACK...rb returned 0
rb returned 0
rb returned 0
rb returned 0
rb returned 1 data:fc,
received 0xfc (good).
init communication 1
wb(fc,) returned 1
rb returned 1 data:fc,
init communication 1
wb(49,) returned 1
rb returned 1 data:8a,
rb returned 1 data:0,
rb returned 1 data:1b,
rb returned 1 data:6,
rb returned 3 data:0,20,f0,
rb returned 3 data:0,fb,6a,
rb returned 3 data:2,0,0,
rb returned 3 data:2,80,0,
rb returned 3 data:4,0,0,
rb returned 3 data:4,c0,0,
rb returned 3 data:5,0,0,
rb returned 3 data:5,80,0,
rb returned 3 data:6,0,0,
rb returned 3 data:6,c0,0,
rb returned 3 data:7,0,0,
rb returned 3 data:7,80,0,
rb returned 2 data:fb,6a,
rb returned 2 data:ff,9c,
rb returned 2 data:2,0,
rb returned 2 data:0,0,
rb returned 1 data:41,
rb returned 1 data:43,
rb returned 1 data:31,
rb returned 1 data:32,
rb returned 1 data:38,
rb returned 1 data:0,

Bootloader protocol version: 0x0A (large S08, read command supported)
Bootloader version string: AC128
System device ID: 0x01B [MC9S08AC(96/128)] rev. 0
Number of memory blocks: 6
Memory block #1: 0x0020F0-0x00FB69
Memory block #2: 0x020000-0x027FFF
Memory block #3: 0x040000-0x04BFFF
Memory block #4: 0x050000-0x057FFF
Memory block #5: 0x060000-0x06BFFF
Memory block #6: 0x070000-0x077FFF
Erase block size: 512 bytes
Write block size:   0 bytes
Original vector table: 0xFF9C
Bootloader user table: 0xFB6A

Are you sure to program part? [y/N]: y
prg_area: 0x000020f0-0x0000fc00
Memory programming: E 0x0020F0 0%

erase_blk: 0x000020f0
init communication 1
wb(45,) returned 1
init communication 3
wb(0,20,f0,) returned 3
rb returned 0
rb returned 0

Thanks.

[gabbo9lli]

I'm able to reprogram my application board's microcontroller.

Now, I should program same microcontroller with single wire option. I find this problem in debug mode.

master>hc08sprg.exe 3 9600 project.s19

---------------------------------------------------------------------------
hc08sprg - Developer's HC/S08/CFV1 Serial Bootloader - $Version: 9.0.57.0$
---------------------------------------------------------------------------
FC protocol versions supported:
        0x01 (HC08)
        0x03 (large HC08)
        0x02 (S08)
        0x06 (long S08)
        0x0A (large S08)
        0x04 (ColdFire V1)
---------------------------------------------------------------------------

Parsed S-record lines: 169  Bytes total: 5286
Source address range: 0x20F0-0xFFFF

Waiting for MCU reset ACK...rb returned 0
rb returned 0
rb returned 0
rb returned 0
rb returned 2 data:fc,fc,
received 0xfc (good).
SEND ACK
init communication 1
wb(fc,) returned 1
want to ignore 1 bytes
rb returned 1 data:fc,
rb data ignored above 1
rb returned 1 data:fc,
init communication 1
wb(49,) returned 1
want to ignore 1 bytes
rb returned 1 data:49,
rb data ignored above 1
rb returned 0
Can't read MCU info. Could be protocol error.
(Or forgot to set single wire mode?)

It looks like that 49,'I', doesn't reject; after, communication stop.

any suggest?

thanks.

[gabbo9lli]

Hi.

I have this hardware configuration.

MC9S08AC128 - 33812 - ISO9141 to RS232 - PC.

I want to download firmware on the MCU from PC.

33812 (transceiver block) is able to manage ISO9141 signal and put it into MCU and viceversa.

It looks like that communication is OK, I see with scopemeter. But I don't receive any aswer from IDENT command, or from BREAK from MCU.

I post my PC output.

D:\working\cf3000\sw\freescale\an2295sw_delphinus\master>hc08sprg.exe 8 test.s19
---------------------------------------------------------------------------
hc08sprg - Developer's HC/S08/CFV1 Serial Bootloader - $Version: 9.0.57.0$
---------------------------------------------------------------------------
FC protocol versions supported:
        0x01 (HC08)
        0x03 (large HC08)
        0x02 (S08)
        0x06 (long S08)
        0x0A (large S08)
        0x04 (ColdFire V1)
---------------------------------------------------------------------------

Parsed S-record lines: 169  Bytes total: 5286
Source address range: 0x20F0-0xFFFF

Waiting for HC(S)08 reset ACK...rb returned 0
rb returned 0
rb returned 0
rb returned 1 data:f8,
received 0xf8 (off-key).
rb returned 1 data:fc,
received 0xfc (good).
init communication 1
wb(fc,) returned 1
rb returned 1 data:fc,
init communication 1
wb(0,) returned 1
Calibration break pulse sent. Count: 1 rb returned 0
init communication 1
wb(0,) returned 1
Calibration break pulse sent. Count: 2 rb returned 0
init communication 1
wb(0,) returned 1
Calibration break pulse sent. Count: 3 ^C

Any suggests?

Thanks

[ok2ucx]

Yes, the suggestion is simple -- you can't use 'standard' embedded part of the bootloader (originally programmed for dual wire communication) for single-wire communication without modifications.

But the mods are fairly simple: embedded slfprg.asm must ignore all characters transmitted (and effectively also received by the embedded). So after tranmission, just wait for the same character received and discard it. That is it.

Pavel

[gabbo9lli]

Hi.

I insert this code (DISCARD_CHAR section) in slfprg.asm for discarding characters just transmitted.

WRITE:   
        BRCLR      TC,SCS1,WRITE
          STA        SCDR
          RTS

DISCARD_CHAR:
        BRCLR     RDRF,SCS1,DISCARD_CHAR
        LDA     SCDR     
        CLRA
        ;LDA     #TEST
        ;BRCLR      TC,SCS1,WRITE
          ;STA        SCDR
          RTS
         
READ:
        BRCLR     RDRF,SCS1,READ
          LDA        SCDR
          RTS

It looks like that it doesn't go. Any suggest?

Thanks

[ok2ucx]

Ummm, in the piece of the code provided, I do not see your WRITE code actually calling the discard part.

I would suggest something like this:

WRITE:  
        BRCLR     TC,SCS1,WRITE
        STA       SCDR

        BRCLR     RDRF,SCS1,*
        LDA       SCDR    
        RTS
        
READ:
        BRCLR     RDRF,SCS1,READ
        LDA       SCDR
        RTS

Pavel

[gabbo9lli]

Sometimes firmware doesn't update.

So, I add this code after first ACK send. In fact, first write routine doesn't enter in WRITE loop.

Now, firmware's upload is OK.

So, the code:

...

        LDA        SCS1
        MOV        #ACK,SCDR
       
        BRCLR   RDRF,SCS1,*
        LDA     SCDR
       
        LDX        #T100MS

...

Thanks.

[Limestone]

Hi Pavel!

I am trying to modify the bootloader slightly and I have so far faild compleatly.

I am using MC9s08qe1238.

 My main goal is to be able to enter the bootloader directly from user code, without having to assign a pin to either control the /RESET pin or use the IRQ pin feature. As my attempts to reset the system only takes me back to my user code, I went for the bootloader instead.

Therefore, I want the bootloader to (regardles of the reset reason) send out 0xFC and 

1: If it gets a correct response, continue with selfprogramming procedure.

2: If it timeouts, jump to user code.

My attempts so far has only put me in a hard reset loop or simply not have any affect at all.

How is this accomplished the best way?

Best regards

Martin

[ok2ucx]

---

Limestone wrote:

Hi Pavel!

I am trying to modify the bootloader slightly and I have so far faild compleatly.

I am using MC9s08qe1238.

 My main goal is to be able to enter the bootloader directly from user code, without having to assign a pin to either control the /RESET pin or use the IRQ pin feature. As my attempts to reset the system only takes me back to my user code, I went for the bootloader instead.

Therefore, I want the bootloader to (regardles of the reset reason) send out 0xFC and 

1: If it gets a correct response, continue with selfprogramming procedure.

2: If it timeouts, jump to user code.

My attempts so far has only put me in a hard reset loop or simply not have any affect at all.

How is this accomplished the best way?

Best regards

Martin

---

Hallo,

to enter the bootloader code you do not need to drive RESET pin. As the bootloader occupies the RESET vector at 0xFFFE:0xFFFF address, any source of reset simply starts the bootloader.

You can enable additional sources of RESET as valid sources of bootloader start with one exception:

- ILOP (illegal operation) must be disabled, otherwise the MCU will cycle forever. Bootloader uses this method to reset MCU and to determine that the user code shall definitely start.

COP (Watchdog) is a good candidate for your code to cause RESET, unless your application needs to reset quickly (enough) after potential code runaway.

You can change the code:

;*******************************************************************************************
main:
        LDA     SRS      ; fetch RESET status reg.
        TSTA             ; check if zero (this happens if RESET pulse is too short)
        BEQ     slfprg   ; if so, jump to self programming               
       AND     #%10000000      ; mask only POR RESET source     
         BNE     slfprg   ; any of these sources, go to self programming

to this:

        AND     #%10100000      ; mask POR & COP RESET sources

and it should work. I haven't tested this though.

Surely you need to have COP enabled (via COPE in SOPT register).

Pavel

[Limestone · Accepted solution]

Hi Pavel and thanks for your response!

It worked like a charm!

I changed that line and stopt feeding my watchdog when I wanted to reboot and enter the bootloader.

Since I spent alot of time searching for a solution like this on the forum and did not find it, mabey this should be documented in someway :smileyhappy:

Best regards

Martin