Bootloader causing random errors

chrischuravy · Joined: 07 Jun 2010 Posts: 5

I am attempting to load a program onto a PIC18F6722 using a modified (to fit my chip) version of the CCS bootloader, and experiencing apparently random glitches once the code is loaded. I have a boot block of 1K words, reset vector is at 0x800 and interrupt vectors at 0x808 and 0x818. Once loaded, the code executes as intended, save for an error that changes with each (slightly different) compilation of the main code. The errors are consistent when using the same compilation, so I don't think it is a problem loading the code. Rather, it seems like a boundary issue or the like. For instance, if I add some garbage code in the region where the error is occurring and recompile, the error will go away and a new one will pop up somewhere else. Compiling and loading without the bootloader results in error-free execution. Any thoughts? Similar problems?

Thanks,
Chris

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

1. Post your compiler version.

2. Also make sure you don't use the XINST fuse. Read the PIC using your
programmer. Does it have XINST set to true ?

chrischuravy · Joined: 07 Jun 2010 Posts: 5

1. I am using PCH Version 4.114.

2. The XINST is not set.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Here are some previous threads on similar problems. They may help.
http://www.ccsinfo.com/forum/viewtopic.php?t=23991
http://www.ccsinfo.com/forum/viewtopic.php?t=42082

chrischuravy · Joined: 07 Jun 2010 Posts: 5

I used the #org directive to prevent the compiler from generating code at the 32k boundaries in program memory. This seems to have fixed the problem. However, I am concerned that future modifications to the program will cause the problem to return. The Programming specification for my chip indicates that the program memory is divided into 16k byte blocks, not 32k byte. Should I include similar #org directives to prevent code being placed at the 16k boundaries as well?

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

I recall that someone tried blocking the 32K boundary (at my suggestion
I think), and he reported it didn't always fix the problem.

Maybe it's possible that if you block the 16K boundaries it will fix it.
Try it.

chrischuravy · Joined: 07 Jun 2010 Posts: 5

Ok, so blocking code at the 16k boundaries did not fix the problem. The moving problem seemed to be occurring in the block (0x10000 to 0x13FFF. In a frustrated attempt to fix the problem, I block code to the entire 16k block. The problem then moved to the next available block(0x14000 to 0x1BFFF). What I am gathering from this is that there is a problem jumping between the blocks that moving my reset and interrupt vectors has uncovered. I have tried using different optimization levels to no avail and am getting very frustrated chasing this down. The only effective solution to this problem I have found has been to randomly move code around and hope that the compiler doesn't generate problematic code. Where am I going wrong?