[solved] USB Bootloader -> program loaded not reliable

[spilz]

I'm not sure to understand what do you refer about PCM_programmer method.

My modification is only like adding my own board to usb_common file. it's only to build the bootloader, and being as close as possible to the original CCS USB Bootloader to facilitate trade in the forum, and delete possible issue of a modify bootloader.

For my program I'm doing like PCM_programmer I guess, or I misunderstand what you said.

I learn lot of thing with your help Ttelmah, thank for that.

[newguy]

Has anyone thought to try this?:
- load PIC using the two different methods, bootloader (faulty) and bootloader + program burned into PIC at same time
- use programmer to read contents of PIC to file for each method
- do a file compare

[PCM programmer]

Yes I have done this. I compared two versions, one with

[Ttelmah]

[spilz]

Oh I see,

I was thinking that this small modification was simpler than giving all the code. My idea was : if you have the demo board, you don't need to modify the file, and can try directly.

I understand now, i will be careful about that next time I post a code.
Thanks

[Ttelmah]

I suspect it is related to RAM bank switching.

I notice that the interrupt code always places it's reserved variables in the low memory.
With the array declared, the timer variables are sitting in bank 4.
When the array is smaller than about 220, the timer variables are in bank 0.

Now the code seems to have the correct bank switches present, so possibly something in the interrupt handler (looking now). #locating the array, means the timer variables can again be located in bank 0. Declaring the array after the timer variables has the same effect and also fixes the problem.
Accessing 'Seconds_flag', forces a bank switch.
The bank switching code is identical in chips compiled for address 0 builds, or 0x2000. I'm suspecting something in the bootloader interrupt relocation.

A look shows what is wrong.

At some point, the interrupt relocation in the USB bootloader, has been incorrectly modified.

It should read:

[spilz]

That seems to solve lot of thing !!
It seems the usb bootloader has an error.

Good job !!!

I'm not sure to understand all, does it change/solve bank stuff ?

Let see if PCM_programmer find something else.

Thanks again both for time spend on my question.

[Ttelmah]

What happens is a bit complex.

#int_global, makes the code become the 'master' handler, without any save/restore.
#int_default, makes the code save all the registers then be called.

Now remember that the code already placed in the upper bank, saves and restores everything.

With #int_global, the hardware saves the W reg, BSR and status, then the code immediately jumps to the code in the upper bank, this then saves everything else, executes the handler, then restores everything and returns, and the return restores the W, BSR & status. What is wanted.

With #int_default, the code in the low memory saves everything, then _calls_ this as the interrupt handler, which then jumps to the upper handler. This call also updates the 'shadow registers, then saves the other registers again. Then jumps to the handler. Problem then is that the upper handler then uses RETFIE1 to return to the low handler. This restores the W, BSR & status back to the value from the low handler, and returns to the handler in the low memory. This calls RETFIE1 _again_. Since the shadow registers were updated by the call from #int_default, the W, BSR and status may have then been damaged. Problem....

[PCM programmer]

Thank you for solving this, Ttelmah.

[Ttelmah]

Your simplified version was what allowed me to track what was happening.
I felt right at the start that it sounded like a BSR problem. This was why much earlier on in the thread, I asked what happened if the array was declared after the timer variables, but this was not tested.
With your version, the first thing was that the code was small enough, and 'complete', allowing me to take the time and make sure that it was correctly being 'relocated' at 2000. Compiled it both at address zero, and relocated, then compared the assembler and checked everything was OK. It was. This then pointed to the problem being in the bootloader, and (of course), except for a slight delay at initialisation, and some registers being changed, the only thing that entered the equation when the bootloader was used, was the interrupt relocation. A look at this code gave the 'ah ha' moment!... I then made a 'combined' file of bootloader and code, and (since USB is not used in the 'normal boot' path), could run this up in the simulator and see what actually happened. Team 'CCS users'.

[Ttelmah]

Just for information, this has now been fixed in compiler version 5.066.