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

[Yoheeb]

Hello.

I was able to try this on windows 7, however my results are of no value yet.  For whatever reason, on both windows 7 and XP, I am unable to get the virtual com port to initialize.  It was with version 9.1, I am going to try 9.2 and see if I have any success.  I am not convinced this issue for me is the driver, although it may or may not work on windows7.

I will get back on this.

[Yoheeb]

Ok, I won't be using 9.2, as I can't find it.

However, I think I need to just "reboot" this process.  Can anyone give me the step by step to using this, over usb, with an S08JM60?

I beleive i flashed the correct bootloader to teh device, I can't for the life of me now flash some actual code.

Literally step by step if you don't mind.  "Open codewarrior, load this specific project, make, go to this menu option to flash the device...blah bla.

now in windows...

for watever reason, I never do get the vcp to show up, not sure why.  So I just want to start from scratch and see what I am missing

Sincerely,

[ok2ucx]

---

Yoheeb wrote:
...

Literally step by step if you don't mind.  "Open codewarrior, load this specific project, make, go to this menu option to flash the device...blah bla.

now in windows...

---

What I did:

1. download http://www.freescale.com/files/community_files/8BI TCOMM/hc08sprg-update-9.2.1.exe.zip

2. open hc08sprg-s08jm-usb.mcp in \hc08sprg-update-9.2.1\an2295sw\src\S08JM-USB\

3. F5 to flash it into JM device (I've tested MCF51JM in JM DEMO board)

4. push & hold PTGD3 button while inserting JM application into USB slot (or any other button you've configured to invoke bootloader)

(4a. for the first time, you will be asked for driver for a new device - you need Win to point to the INF file from: http://forums.freescale.com/freescale/attachments/freescale/8BITCOMM/16526/1/Freescale_CDC_Driver_V2...)

(4b. a new COM port named "Freescale CDC device" will come up in Device manager)

5. run hc08sprg.exe (or GUI application)

6. load application (you may try the one attached)

7. application works - the hid-demo application will install new HID device (mouse) that slightly moves left and right

I've tested this both on Win XP SP2 & SP3 as well as on Win 7. Seamlessly works.

Pavel

[Yoheeb]

Thank you thank you thank you.  This worked.

I honestly have no idea why it wasn't working before, as this is pretty much exactly what I thought I was doing.  I apparently was missing something, or just had some strange juju working against me.

I appreciate the quick, helpful response.  Sorry I had to seem like such a burden, this was just one of those cases I needed to step back, start from scratch, and assume I was an idiot;  thanks for not treating me like one, btw.

Again, this bootloader is great that's to all that have contributed as it has/will save me a ton of time and maybe a few of the hairs I have left.

Anyway, I wanted to actaully add something useful to the thread:

This worked on windows 7 (32 bit) with the updated CDC driver provided, it also worked with version 9.1 of the device side bootloader, and the 9.0 version of the pc side flash utility (which I don't beleive actually changed).  The driver also worked on 64 bit XP

Cheers and happy romming.

[RogerSchaefer]

Hi,

I am using the OSBDM to load the serial bootloader.  Until recently the OSBDM did not set the trim and I used a tedious manual method to determine a trim value.  Using the tedious method on a MC9S08SE8 I determined that the trim value for a particular chip was $24.  Using that value for trim your bootloader worked fine and my program worked fine.  The SCI and timers worked correctly using all default values for the ICS.

Now a new program is introduced, the "HCS08 Flash Programmer", that loads programs AND sets trim using the OSBDM.  I think GREAT, I won't have to use the tedious method to determine trim or use Codewarrior.  Now the problem: the HCS08 Flash Programmer sets the value for the trim for this chip and several others I tested at $C5 ( or similar) and requiring the application program to change the value of BDIV in ICSC2 to get the desired bus clock.  Apparently the author of the HCS08 Flash Programmer thinks that my value for trim is causing the chip to run out of spec.

My question is: How did you determine trim?  Did you use a P&E programmer?

Right now my concern is with the MC9S08SE8 but I think that the HCS08 Flash Programmer will do the same thing with any 9S08 that uses the ICS Version 3

Roger

[gabbo9lli]

Hello.

I'm working with MCF51AC128A.

I would use bootloader with half-duplex communication. So, I want to discard char after writing.

I modify WRITE in code.

WRITE:
             move.b  SCIS1,d1
             btst    #6,d1
             beq.s   WRITE
             move.b  d0,SCIDR
            
             bra     DISCARD_READ
             
             rts

DISCARD_READ:
             move.b  SCIS1,d1
             btst    #5,d1
             beq.s   DISCARD_READ
             move.b  SCIDR,d7
        
             rts 

I improve my code, but it doesn't.

I don't receive any #ACK to PC master.

Any asuggest?

Thanks.

[gabbo9lli]

Hello.

I'm working with MCF51AC128A.

I would use bootloader with half-duplex communication. So, I want to discard char after writing.

I modify WRITE in code.

WRITE:
             move.b  SCIS1,d1
             btst    #6,d1
             beq.s   WRITE
             move.b  d0,SCIDR
            
             bra     DISCARD_READ
             
             rts

DISCARD_READ:
             move.b  SCIS1,d1
             btst    #5,d1
             beq.s   DISCARD_READ
             move.b  SCIDR,d7
        
             rts 

I improve my code, but it doesn't.

I don't receive any #ACK to PC master.

Any asuggest?

Thanks.

[brauliochi_thin]

Is there any chance to reprogram with this bootloader with processor expert??? thanks, best regards

[gabbo9lli]

hi.

I use bootloader for MCF51AC128A.

I modify source code for running in half-duplex mode adding this part after WRITE subroutine.

WRITE:
             move.b  SCIS1,d1
             btst    #6,d1
             beq.s   WRITE
             move.b  d0,SCIDR
             
             bra     DISCARD_READ
             
             rts
/*******************************************************************************/        
READ:
             move.b  SCIS1,d1
             btst    #5,d1
             beq.s   READ
             move.b  SCIDR,d0
        
             rts
/*******************************************************************************/        
DISCARD_READ:
             move.b  SCIS1,d6
             btst    #5,d6
             beq.s   DISCARD_READ
             move.b  SCIDR,d7
             move.b  #0x0,d7
             move.b  #0x0,d6
        
             rts

User program seems loading correctly, but doing RESET do not start.

In log file from PC communication, I see that this bootloader do not make syncronization phase (PC sends break, bootloader respond FC).

Any suggest?

thanks in advance.

gabbo

[RogerSchaefer]

Hello,

I've tried the S08SE alpha version and can't get to work.  I do have experience using the serial bootloader with S08SH, S08QE and S08QG. 

The hc08sprg.exe can't seem to get an ACK.  I am using ver 9.0.41

Has anyone else tried this alpha version?

Roger

[RogerSchaefer]

Hello,

More info on S08SE alpha version........

I checked the source and found a problem with setting BDIV in ICSC2.  When I chenged BDIV to = 01 and assembled I could get a good ACK of $FC

However, I get this message:

"ERROR!  The SDID of the device [0x025] is too high and not (yet) supported!  Check AN2295SW for update!

Can't read MCU info.  Could be protocol error."

I downloaded the latest version Freescale of AN2295SW and the version number is 9.0.41.0

If there is a later version where do I get it?

Roger

[RogerSchaefer]

Hello,

Still more on S08SE alpha version ...

I found a later version of hc08sprg.exe  Look at Message 40 of this thread.

That download has version 9.0.57.0 of the hc08sprg.exe program which does work if you fix the BDIV=01 problem.

Careful: the download in Message 40 also has the older version of hc08sprg.exe

Roger

[cboava]

Hello Pavel,

you said AC60 and AW60 families are the same, but aren't the interrupt vector tables different?

According datasheets, interrupt vector table for AC60 starts at FFC6 adress, while in AW60 family the initial adress is FFCC.

So, in the slfprg-s08acaw.asm program, shouldn't the values of labels REL_VECT and INT_VECT be different for AC60 family?

Thanks in advance,

Christian.

[ok2ucx]

Hi Christian,

you're right, these families are not really identical. I've corrected REL_VECT and INT_VECT values in this port, this was a minor change. Find corrected file on the link below:

http://www.freescale.com/files/community_files/8BITCOMM/hc08sprg_s08acaw_beta2_exe.zip

Thank for pointing this out. Regarding SE family, I need to look at this once more.

Regards, Pavel ok2ucx

an2295 bootloader developer & coordinator

[cboava]

Pavel,

thank you for replying.

However, I still can't load a user program using this new bootloader version.

See the messages below when I try to load my user code:

Parsed S-record lines: 791  Bytes total: 25131

Source address range: 0x1860-0xFFFF

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

Calibration break pulse sent. Count: 1

Bootloader protocol version: 0x02 (S08, read command supported)

Bootloader version string: AC60

System device ID: 0x01D [MC9S08AC(32-60)] rev. 0

Number of memory blocks: 2

Memory block #1: 0x0870-0x17FF

Memory block #2: 0x1860-0xFDC5

Erase block size: 512 bytes

Write block size:  64 bytes

Original vector table: 0xFFC6-0xFFFF

New vector table:      0xFDC6-0xFDFF

WARNING! S19 image will not fit into available memory (at address 0xFFBD)!

Are you sure to program part? [y/N]: y

Memory reading:     R 0xFFBD 99%

Verification failed at address 0xFFBE, image: [0xFF], MCU: [0x73]

Program memory failed.

Would you have any ideia about what's happening?

Thanks once more.

Christian

[celsoken]

Dear Christian,

Is this the same request from Jucelino?

Cause he's working on exactly the same situation.

Cheers,

Celso

[ok2ucx]

Hi, time to read documentation  This is not bug, this is a feature. 0xFFBD is actually NVPROT FLASH register that is occupied by bootloader (see http://www.freescale.com/files/microcontrollers/doc/app_note/AN2295.pdf section 4.6.3).

Simply, anything in user S19 that is outside USER Flash:

Memory block #1: 0x0870-0x17FF
Memory block #2: 0x1860-0xFDC5

 and outside interrupt vectors

Original vector table: 0xFFC6-0xFFFF

will generate that warning and the memory location will not be programmed properly.

Thus if you see the warning, look at the address and make sure this memory location is not used in your code. Here, remove your user code NVPROT that sets it to 0xFF.

Regards, Pavel ok2ucx

an2295 bootloader developer & coordinator

Message Edited by ok2ucx on 2009-09-04 03:37 PM

[cboava]

Pavel,

now you are completely right!

I just removed the initialization of NVPROT (and NVOPT as well) in my user code and bootloader worked perfectly!

Thank you very much for this help.

Best regards,

Christian.

[chapster]

I am using the QE128 bootloader (update 9.2.1) on a QE64 as I will soon need to upgrade the memory size.  My code runs fine programming through BDM when placed in pages 0 and 2, or 4 and 5 (banked model).  However, when programming through the bootloader the code using pages 0 and 2 does not work when the same file using pages 4 and 5 does.  From my prm file I comment out one of the 2 lines below.  All other source files are identical.

DEFAULT_ROM, PAGED_ROM /* routines which can be banked */

/*INTO PPAGE_0,PPAGE_2,ROM1;*/

INTO PPAGE_4, PPAGE_5,ROM1;

When reading back the flash memory I find that the non paged area 2080 -2200 is blank (0xFF) in the non working code despite the original s19 file having interrupt service routines here (which is why it doesn't work).  When using pages 4 and 5 the same ISRs are placed in the same memory location and the bootloader loads them in correctly. 

Do you know wht the bootloader is doing this?  Is it anything to do with using the QE64? My understanding is it no different from a QE128, just that the out of range memory is untested but I dont see how that could cause this problem.

Please help!

[ok2ucx]

Hi,

this looks strange. I've created a test code that puts various pieces of data into various pages. My test PRM file looks like this:

/* This is a linker parameter file for the mc9s08qe128 */
ENTRIES
 field field0 field2 field4 field5 field6 field7
END


NAMES END

SEGMENTS
 /* Here all RAM/ROM areas of the device are listed.
 Used in PLACEMENT below. */
  Z_RAM     =  READ_WRITE   0x0080 TO 0x00FF;
  RAM       =  READ_WRITE   0x0100 TO 0x17FF;
  RAM1      =  READ_WRITE   0x1880 TO 0x207F;
  /* unbanked FLASH ROM */
  ROM       =  READ_ONLY    0x2080 TO 0x7FFF;
  ROM1      =  READ_ONLY    0xC000 TO 0xFFAD;
  /* banked FLASH ROM */
  PPAGE_0   =  READ_ONLY    0x008000 TO 0x00A07F;
   PPAGE_2   =  READ_ONLY    0x028000 TO 0x02BFFF;
   PPAGE_4   =  READ_ONLY    0x048000 TO 0x04BFFF;
   PPAGE_5   =  READ_ONLY    0x058000 TO 0x05BFFF;
   PPAGE_6   =  READ_ONLY    0x068000 TO 0x06BFFF;
   PPAGE_7   =  READ_ONLY    0x078000 TO 0x07BFFF;
 END

PLACEMENT
 /* Here all predefined and user segments are placed
 into the SEGMENTS defined above. */
    DEFAULT_RAM           /* non-zero page variables */
                          INTO  RAM,RAM1;

    _PRESTART,            /* startup code */
    STARTUP,              /* startup data structures */
    ROM_VAR,              /* constant variables */
    STRINGS,              /* string literals */
    VIRTUAL_TABLE_SEGMENT,/* C++ virtual table segment */
    NON_BANKED,           /* runtime routines which must not
          be banked */
    DEFAULT_ROM,
    COPY                  /* copy down information */
                          INTO  ROM;

     PAGED_ROM_0           INTO  PPAGE_0;
    PAGED_ROM_2           INTO  PPAGE_2;
    PAGED_ROM_4           INTO  PPAGE_4;
    PAGED_ROM_5           INTO  PPAGE_5;
    PAGED_ROM_6           INTO  PPAGE_6;
    PAGED_ROM_7           INTO  PPAGE_7;
    PAGED_ROM             INTO  ROM1;

    _DATA_ZEROPAGE,       /* zero page variables */
    MY_ZEROPAGE           INTO  Z_RAM;
END

STACKSIZE 0x50

VECTOR 0 _Startup

 and my actual test code is as following:

#include <hidef.h> /* for EnableInterrupts macro */
#include "derivative.h" /* include peripheral declarations */


#pragma CONST_SEG PAGED_ROM
const char field[]= "\377\377\377 00000PAGE x";
#pragma CONST_SEG DEFAULT

#pragma CONST_SEG PAGED_ROM_0
const char field0[]= "\000\000\000 00000PAGE 0";
#pragma CONST_SEG DEFAULT

#pragma CONST_SEG PAGED_ROM_2
const char field2[]= "\002\002\002 00000PAGE 2";
#pragma CONST_SEG DEFAULT

#pragma CONST_SEG PAGED_ROM_4
const char field4[]= "\004\004\004 00000PAGE 4";
#pragma CONST_SEG DEFAULT

#pragma CONST_SEG PAGED_ROM_5
const char field5[]= "\005\005\005 00000PAGE 5";
#pragma CONST_SEG DEFAULT

#pragma CONST_SEG PAGED_ROM_6
const char field6[]= "\006\006\006 00000PAGE 6";
#pragma CONST_SEG DEFAULT

#pragma CONST_SEG PAGED_ROM_7
const char field7[]= "\007\007\007 00000PAGE 7";
#pragma CONST_SEG DEFAULT

void main(void) {

  PTCDD = 0x0F;

  for(;;) {
    __RESET_WATCHDOG(); /* feeds the dog */
   
    PTCD ^= 0x0F;
  } /* loop forever */
  /* please make sure that you never leave main */
}

so at the end it generates following S-record:

S02400005A3A5C746D705C686330385C51453132385C62696E5C50726F6A6563742E61627352
S12320808B899EFE05F6AF019EFF05888A81A7FCC621054C95E701C621044CF732210620AD
S12320A01F898BF687E6024C9EE706E603EE018A4C20037FAF014BFB9E6B05F78A88AF049D
S12320C09E6B02DD9E6B01D9322108898BADB1974C9EE703ADAA4C9EE7044A2603510018F1
S12320E0AD9E878AAD9A972005AD95F7AF019E6B04F79E6B03F320D5A7068145015094AD97
S12321008DCC21160000210A21240000000000000000000000006E0F05C71800B604A80FE9
S1092120B70420F50000E5
S113800000000020303030303050414745203000EF
S113C000FFFFFF203030303030504147452078006A
S105FFFE20FBE2
S21402800002020220303030303050414745203200E4
S21404800004040420303030303050414745203400DA
S21405800005050520303030303050414745203500D5
S21406800006060620303030303050414745203600D0
S21407800007070720303030303050414745203700CB
S804000000FB

Now: I've loaded this S-record into the S08QE128 via Bootloader and also directly via BDM.

I haven't experienced any difference in where the code has been programmed (except bootloader missing). Especially when looking at address 0x8000 with PPAGE set 0, I can correctly see PAGE0 content.

If you don't mind sending me your code (at least the skeleton), so I can see more in details what is happening with your code. I can give you my email address via private message.

Pavel

Message Edited by ok2ucx on 2009-09-30 04:43 PM

[chapster]

Thanks for the response.

I think I have got this figured out but would be good for someone else to confirm it.

If you allocate all of PPAGE_0 memory to field0 by making it 8320 bytes long then you can see the problem I am coming up against.  Loading it in via BDM if fine.  If you then use the bootloader to put the same s19 file on the chip then the code at 2080 disappears which is what I reported earlier.  I think the reason is that when the bootloader writes to PPAGE_0 A000 to A07F it will erase the whole block first up to A1FF which overlaps with ROM which starts at A000 (8000 + 2000).  If I make ROM start at 2200 in my linker file everything is OK. 

Does this sound right?

[ok2ucx]

---

chapster wrote:

Thanks for the response.

I think I have got this figured out but would be good for someone else to confirm it.

If you allocate all of PPAGE_0 memory to field0 by making it 8320 bytes long then you can see the problem I am coming up against.  Loading it in via BDM if fine.  If you then use the bootloader to put the same s19 file on the chip then the code at 2080 disappears which is what I reported earlier.  I think the reason is that when the bootloader writes to PPAGE_0 A000 to A07F it will erase the whole block first up to A1FF which overlaps with ROM which starts at A000 (8000 + 2000).  If I make ROM start at 2200 in my linker file everything is OK. 

Does this sound right?

---

Yes, this is the right cause of this issue.

Before writting to PPAGE_0 0xA000 page, the complete block (0xA000-0xA1FF) is erased. That includes 0x2080-0x21FF area that has been programmed during the process before. I do not quickly see any sensible solution without braking the complete structure of hc08sprg.exe how to avoid this unknown erasure. This will become known limitation.

As a quick workaround (just to avoid such non-functional booting), the bootloader's memory map could be modified, so the area between 0xA000-0xA07F (or 0x2080-0x2200) will not be a part of the memory map (available via bootloader). This way the user will be warned.
 

I.e.first memory block

Memory block #1: 0x002080-0x00FB9F

will split into the two (to avoid 0xA000-0xA07F block):

Memory block #1: 0x002080-0x009FFF

Memory block #2: 0x00A080-0x00FB9F

or the start of this block will just move:

Memory block #1: 0x002200-0x00FB9F

I would prefer the first solution.

Pavel

P.S. Same issue appears on S08AC128 and also S08DZ128 families. I will make the modifications to the relevant source codes before release 10. Thanks for reporting this bug.