Developers Bootloader AN2295, HCS08, Special issues with USB

[TurboBob]

I am having decent results using AN2295 in my product, it has an FT232RL on board as the USB interface. There are several issues related to the USB.

Since I don't have an I/O I can use as a boot trigger (like IRQ), the only entry mode to bootloader is the power on delay. Due to the lagtime associated with the USB port - serial port waking up in the PC, the power on delay doesn't work to signal the PC.

I made a change in the bootloader, I send a trigger message to my application so it can vector into the bootloader. This works ok.

Here's the problem: If reprogramming fails, I have no way for the customer to re-enter programming mode.

What I want to do is change the sequence of programming so that if the entire program is not loaded properly the bootloader will start.

Anyone modded the Master program? I want to write a couple bytes to a known location in the flash once the program is loaded and functional. A checksum would be awesome, but just a status word would work.

Any other (better) solutions?

Thanks!

TurboBob

[TurboBob]

a couple guys asked how I am jumping to the bootloader from my application. 

I modified the an2295 program to performa  checksum of the application space and only jump to is if 

the checksum was valid

I modifed the master program to calculate and insert the checksum, as well as skip the baud rate check.

(I will post that when I get to my other computer.)

My host program sends this sequence before executing the "dos" program

I have a spot in the application that jumps to "jumphook" in the boot if a specific sequence of characters

is received from the PC.  The jump address is sent with the reboot command.

   else if(SerialCommand == 0x42)     // Reboot!
      {
      Serial_RecvChar(&RxByte1);
      Serial_RecvChar(&RxByte2);
      if(RxByte1 == 0x42 && RxByte2 == 0x42 ) // BBB
        {
        Serial_RecvChar(&RxByte1);
        Serial_RecvChar(&RxByte2);
        pointer = ((unsigned int)RxByte1)<<8;
        pointer += RxByte2;
       
//        LED1_SetVal();


        Cpu_DisableInt();
        asm
          {
          ldhx pointer   ; jump vector
          jmp ,x
          }

Bob

[TurboBob]

here is the main routine from the bootloader PC app.

it calculates and embeds a checksum in the file.  it triggers a jump to boot in the target by

sending a short message which includes the jump address.

Bob

[rocco]

This is what I've done on the HC08GP32:

1) I modified the bootloader such that it always programs the reset vector to point into itself. The bootloader always gets control on a reset.

2) the fist thing the bootloader does is compute the checksum of the entire flash contents. It compares that value with the value stored at address 0xFDFE:0xFDFF (last two bytes of the flash).

3) if the checksum passes, the normal runtime firmware is started. If the checksum fails, the bootloader is started.

I also added a command routine to the bootloader to compute the checksum for the flash, using the same routine that checked it upon reset, and store that value at 0xFDFE:0xFDFF. The host will issue that command to compute-and-store as the very last step in the downloading/programming sequence.

If the downloading fails for any reason, even if the flash get corrupted later, the checksum will be incorrect, and the bootloader will start upon reset.

[TurboBob]

Sounds like exactly what I need. Can I convince you to share the source code?

I have a clear spot at the beginning of my code block I want to put the CS in. What I will probably do is to clear 6 bytes so I can have code addresses along with the checksum embedded. This way my application can do a periodic CS in its spare time (paranoid, I know)

Bob

[rocco]

Hi, Bob:

Well, here it is. I hope you don't mind assembler. We hadn't discussed that issue before.

The code was originally based on Motorola's AppNote AN2295, "Developer’s Serial Bootloader for M68HC08". I made it GP32 specific, but with EQUates, so that it is easy to adapt to other MCUs. I added support for hardware type-checking and versioning, as well.

This file would be 'included' in your source file. Prior to this file being called, you need to define a macro called "INIT" that will prepare the necessary I/O pins for booting your specific hardware. On my boards, I turn on a red LED to indicate I'm in BOOT mode, and I enable an RS485 line-driver on the boards where I boot through RS485.

As currently defines, the code it generates lives at the beginning of flash, in its own section, and takes 512 bytes. The .prm file needs to reflect this, by defining the section as "BootCode". It is self protecting, in that it will not let you program over that section. It will also not allow you to program the reset vector to point to anything other than itself.

I'm sure that I have left important things out, so don't hesitate to ask. I can send you my .prm file, if that would help. I also have a GUI download program for the PC that connects, programs and verifies the firmware. It is written in C#.

[TurboBob]

I would be very interested in the GUI programming stuff. I was going to convert the AN2295 to "GUI" sometime, just never found the time. I have been doing PC programming in C++ Builder lately, but have C# and VC++ here also.

Assembler is no problem, I started in assembler many years ago and am pretty comfortable with it....

I hope that I can return the favor sometime!

Bob

[bitwok]

Hi Bob,

You may want to try the MC9S08JM60 micro with USB interface. I just developed a series of "how-to-videos" on how to make a GUI for your USB application. At this moment they are published in http://bitwok.googlepages.com/home but they will be published soon in the Freescale website.

I also developed a DLL for making a USB bootloader in your GUI (http://bitwok.googlepages.com/home2).

You may want to take a look if you are interested.

Regards!