yes, another bootloader question re: ccs bootloader

[dan king]

I have decided to explore the ccs provided bootloader and am using compiler ver 3.130. The code sample compiles ok but when I use the ICD to program a 16f877, MPLAB warns that the code is addressing beyond address 0x2000 ?? I programmed the part anyhow and the bootloader begins to operate but when the L is entered to invoke the loader and I send the hex file via the send text file nothing happens. I am using hyperterm set for Xon/Xoff at 9600 baud. Any suggestions would be welcome.

Thanks Dan

[PCM programmer]

The Config Word for a 16F877 is at address 0x2007.
Hex files use byte addresses, so this will be seen as 0x400E.
Example:
:02400E00713F00

Is it possible that your programmer is set to prevent the Config Bits
from being programmed ?
If you think code has been put at an address above 0x1FFF, then
check the HEX file.

With respect to the apparent lock-up, the CCS example doesn't
have the 'Errors' parameter in the #use rs232() statement. You
could add it. You'd still get the error, but at least it wouldn't lock
up the program.

One simple way to track the progress of the program is to put in
little putc() statements, such as putc('A'), putc('B'), putc('C'), etc.
and when it locks up, you can see right where it happened.
I don't know how much space is left in that loader to allow for adding
these debug statements. You should check the .LST file to see.

[dan king]

I have included the list file, it appears that the bootloader code is being overwritten? Shouldn't the majority of the code be located at the high end of program memory? I'm not used to reviewing LST files so I'm interpreting that the address is the left most column and it appears that a lot of the boot code is low in memory.

You mentioned that the hex file can be viewed to verify the addressing, can't the lst file be used as well? I am not familiar with the format for hex files, so I don't see the pattern in your Example :(

I believe the config bits are being programmed with the ICD programmer because I have been using a assembly version bootloader that someone gave me and that programs fine. I wanted to start using a C loader that I could understand a little better. Not having much success with that

I don't think I'm getting lockups, I think the boot code is being overwritten because a reset on the board after a transfer attempt does absolutely nothing. I have to reprogram with the ICD to get the code to respond again.

I typically use your suggested method of tracing with messages by sending characters, just didn't get that far yet.


Thanks for your help so far.

[dan king]

I found a good app note from microchip (AN732) detailing the hex format. Thanks for the direction, I understand your previous example now and can verify that I don't have code above the max program limit.

[PCM programmer]

Before we go any farther, can you do these two things ?
1. Put NOLVP at the end of the #fuses statement.
2. Put ERRORS at the end of the #use rs232() statement.
The changes are shown in bold, below.

#if defined(__PCM__)
#include <16f877.h>
#fuses HS,NOWDT,NOPROTECT, NOLVP
#use delay(clock=4000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)

[dan king]

Ok, I added the lines you requested but I still get the same response. When I typed my initial post I stated that when I pressed the 'L' nothing happened when I attempted to send the hex file. At that time I had the ending program address for the ICD set to 1EFF, not sure why so I changed it to 1FFF. Since then I get one black spade returned when I attempt to send the hex code. After that, nothing as in I have to reload the bootloader with the ICD because I believe the bootloader was overwritten. This is still the same results after the modifications you requested I make.

Do I need to add a #ORG to the code to be downloaded with the bootloader to prevent the new code from overwriting the bootloader?

[Jeff King]

Dan:

Try SIOW.EXE which is available via the "TOOLS" window of the CCS compilier for your uploaded. Under the file menu pulldown, there should be a selection for "Download Software". In developing a client app for the bootloader, I used SIOW as my reference, and it always seemed to work if things where OK with the bootloader.

Also see my recent posting on the bootloader example. Not heard back from CCS but I wouldn't assume things are kosher in the bootloader.

Looking at your code you have:

[dan king]

Jeff,

I guess my rev of loader.c is older than yours because the code snippet you included in your previous post is not quite the same in mine.

Either way, I don't think your suggested change will work because Loader_end is the max address in program memory and we just want to check that the new code won't over write the boot code, so checking to verify that addr > loader_end isn't valid. The sample code I have checks for the code address to be < LOADER_ADDR which is valid because that is the start of the bootloader code and as long as we're less than that we should be OK.

One of the several problems I found with the CCS example is that too much code is resident in low memory and gets overwritten with user code which then renders the bootloader useless. The LST file uncovers this problem.

FWIW: I gave up on the CCS bootloader because it needed too many additions to get it to a point of being really useful. A better start is to check out the bootloader code from theByteFactory.com - codeloader_m.c That application works well and covers a lot of the bases for error checking and relocating the reset vector.

Thanks for your input.

Dan