bootloader

[SeeCwriter]

I'm trying to use the bootloader feature with an 18F67K22 with IDE 5.054.

I have an application that runs on the PIC. I added an include for bootloader.h and recompiled. I then compiled the bootloader project and programmed the PIC with it using the ICD. I put the PIC into programming mode, verified by a printf() output indicating as such.

Then I used siow.exe to download my program. The SIOW port was set for 9600 baud, N81, no flow control. It downloads the program sucessfully, but my program does not run, even though in the output pane of the CCS IDE displays messages:

"Bootloader: File Downloaded at 01:43 PM"
"Bootloader: Program Running"

I noticed in the bootloader code that it uses XON/OFF for flow control so I enabled software flow control in SIOW. With that enabled, it won't download. It gives a timeout error.

Also in the bootloader code, when programming mode is not detected it calls function "application" which is nothing more than a while statement. How does control transfer to my program?

[PCM programmer]

The bootloader program that is compiled and then programmed into the
PIC with the ICD is called Ex_bootloader.c.
The comments at the beginning of that file say you must hold a button
down while resetting the PIC, in order to cause the bootloader to start
downloading a HEX file. The comments say the button is on pin B5,
but that's not accurate. This line of code says it's on pin A4.

[SeeCwriter]

The example bootloader program has all that, but I didn't use the example program.
I used the project wizard to create a bootloader project. It created a main.c
file that looks nearly identical to the example file. The only differences were
that there was no button input defined, and the input statement just had PIN_A4
as its argument.

The only thing I changed to main.c was to add a #define for the button input and
use it as the input argument. The button input is PIN_E3. There is nothing about
special about A4 or A5 is there?
And to header file that was created I added #use delay and #use 232 defines.

The button input does work. I've verified it with a printf() statement.

Here are the two bootloader files:

[davidd]

1. Yes you must use flow control. This is because the PIC is running the bootloader code at the same time it is loading yourproject.hex. From what I have seen, all the bootloaders use software flow control.
2. Once you have the bootloader programmed into your chip and nothing else:
> when you reset the micro and the bootloader runs, it has 2 options:

A. bootloader is invoked and it waits for incoming data yourproject.hex.

B. bootloader is not invoked so it jumps to <application start>.

> If you ONLY have the bootloader in the micro and it jumps to <application start> what is it supposed to run?

> This is where "application()" comes in.
A. if ONLY the bootloader is in the micro: boot loader runs <application>
B. if YOURPROJECT.HEX has been loaded into the micro: bootloader runs <main>

<application> and <main> are written to the SAME address<application start>, so when YOURPROJECT.HEX is written to the micro it overwrites the <application> with <main>

Having said that, if just the bootloader is present in the cpu, what you can do is put a beeper in the application() function.
SO when the micro is RESET, but bootloader is NOT invoked -- start beeping until the button is pressed, then run CPU_RESET() again. this way it tells the setup guy there is no YOURPROJECT.HEX loaded yet. And gives an opportunity to restart again in to invoke bootloader mode

~Dave

[SeeCwriter]

Ok, that's kind of what I thought about how the transfer of control was done.

But the real problem is that when I enable flow control siow timesout after sending the first line. Is there some other setting I'm missing in siow?

[davidd]

ok
have you checked to make sure the XON and XOFF designator characters match?

[newguy]

Take this with a grain of salt because I did it many years ago, but if I remember correctly, the one time I played with a bootloader, I found that SIOW didn't work at all to transfer the program. I forget what serial program I ended up using, but I know it wasn't CCS' SIOW.

[SeeCwriter]

Yes, they match.

XON = 0x11
XOFF = 0x13

[davidd]

ok have you tried reducing buffering on your serial port?
it would be under device manager serial ports...

Anyway try the CCS standalone bootloader GUI I had this working but sometimes it would hang and timeout mid-way through.

see if it works for you...
http://www.ccsinfo.com/downloads.php
scroll down to CCS bootloader

[davidd]

if I edit one of my posts will the thread initiator receive a notification (if it is enabled for him/her)?

[SeeCwriter]

I reduced my PC's comport buffer sizes to 1. SIOW still times out after sending the first line.

I downloaded ccsbootloader.exe and tried it. It gets about halfway through the download
then stops with a "PIC not responding" message. I tried it numerous times and it always
fails at the same spot with the same message.

I tried a different terminal program, Microsoft's MTTTY Terminal with XON/XOFF enabled.
It appears to download the whole application file and finishes normally, but the program never
runs.

[davidd]

ok
I had the same issue with CCS bootloader.exe and my code was fine.

since you seem to be able to dload yourproject.hex, check the asm list file for bootloader.hex.

find the application start address, then make sure ANY bootloader code resides BEFORE the application start address

[SeeCwriter]

The bootloader starts a address 0 and ends at address 0x398. The segment reserved for the bootloader is 0 to 0x4FF.

My application starts at 0x500.

However, in the bootloader, the function application() starts at LOADER_END+2. Does that mean the function is at 0x501?

Update: The bootloader list file shows application() at address 0x500. I don't know how this new math works, 0x4ff + 2 = 0x500, but it's at the right location.

[davidd]

look at the asm file for bootloader.c and see what physical address application() starts at.

Then goto yourproject.c and see where main() is located -- these should match.

[SeeCwriter]

They match. Both start at 0x500.