[solved] USB Bootloader -> program loaded not reliable

[spilz]

Thanks a lot for your help

[PCM programmer]

OK, I've duplicated the problem. When the 1024 byte array is
commented out, it blinks once every 7 seconds. When the array is
included in the program, it blinks once every 2 seconds. You referred
to it "going crazy", but I don't see that. I see it blinking every 2 seconds.
Actually there is more. If I unplug power from the board and plug it in
again, it first blinks 4x at a 1 second rate. Then it slows down and
continues blinking at a 2 second rate.

But that shouldn't happen. There must be some reason for it. I'll try
to investigate that tomorrow.

I tested this problem with CCS vs. 5.064, and an 18F4550, on a modified
Picdem2-plus board (the older, non-rohs version).

[spilz]

It's because the 4 blinking at start that I said "crazy".
It's me who become crazy too ... ^^

The point is there is something not normal when using bootloader.

This is a basic example where I get this issue, but as you can see on other topics, I got issue with usb as serial too (loaded with USB bootloader).

Your test confirms it's not a hardware issue.

Thanks for your help.

[spilz]

I read the rom after loading the program with usb bootloader, the bootloader seems to work right (write the data to the good place in rom).

I think the issue comes from CCS when compiling the program not at start.

[Ttelmah]

I have the same chip running with code using 93% of the ram and over 75% ROM, using a bootloader without any problems. I'd actually be most suspicious it is something to do with the clock setup/switching.

The settings are a little 'odd'. Running Timer0 off the internal oscillator, yet setting the secondary oscillator to high power. Given the timings are dependant on the timer0 module, it looks suspiciously as if it is sometimes getting clocked at perhaps 4* the rate expected. If the actual pulse durations are correct (so the main CPU is not changing frequency), this might be the area to look.

As for 'why' the array makes a difference, it'd also be worth experimenting with deliberately locating this in different ways, and see what happens. So declare it after the timer variables for example, or inside main.

I had an 'oddity' with this combination when I first started coding for it, that variables behaved differently when declared as 'static', to how they declared with an initialisation to 0 (which is all that static should change for a global variable).

[spilz]

I'm using 18F2550 for several years, with big program and using a USB bootloader, and in general they work well.

but sometimes even with small program, I got issue when I use long array, or when I want to use USB as serial. I thought that the issue was from my bad knowledge, and I never try to burn them directly without bootloader.

this night I did tests with différents programs which i had issue, burning them directly, and they works well without bootloader ...

there is really something wrong with this, but not "always".

If this issue appears in this 'basic' exemple, we can suppose it can appears on more complex program.

PCM programmer :

[Ttelmah]

Years ago, large arrays had problems.
This applied however the code was loaded.
However on modern PIC's with the modern compilers, this no longer generally applies.
As I said earlier in the thread, the only thing changing with the large array, is the placement of the other variables.

[spilz]

I'm ok about the placement of other variables, but why using bootloader change something ?

[Ttelmah]

I'll wait to hear what PCM_Programmer finds. Things that are affected, are the relocation of the interrupt vector, and you have to remember the code then goes through the initialisation in the bootloader, before arriving at the initialisation in the main code.

This is why NOIOL1WAY, is pretty essential, otherwise a PIN_SELECT in the main can get blocked. Doesn't apply to the older chip that PCM has managed to duplicate the problem on though.

[spilz]

You teach me about NOIOL1WAY, I didn't know that
Thanks

[Ttelmah]

With IOL1WAY, pin settings can only be programmed once, and are then locked.
Problem is that if the bootloader sets the pins up, and the settings do not completely match the ones used in the main code, the settings are made in the bootloader, and cannot then be changed when the main code runs....
Problem.

NOIOL1WAY, remove this lock (the settings still have protection, requiring a special 'unlock' sequence to change), however then allowing the main code to set the pins as needed.

Generally, you should not be using a modified usb_common.
The usb_common file is chip settings for the example. Normally you should just be loading your chip settings, then the usb driver. Fiddling with the example is an unnecessarily complex way of doing things.

[spilz]

The usb_common file is for specific chips on specific boards, if you don't have them, like me, you have no choice, you have to adapt this file :(

[PCM programmer]

I don't have a definitive answer yet. I just have experiments. I'm sorry.

In the test program shown below, I have stripped it down to just one byte
that is incremented by the 1 second timer. Then we don't have to worry
about multi-byte issues. And, it still showed the problem.

The problem is, if the 'delta' test of "greater than or equal to" is used,
then 'delta' changes and displays incorrect values inside the
if() statement. The result is incorrect delays between led flashes.
The delays should be 7 seconds every time. But are not.

One "fix" that appears to work is to add a flag to the timer interrupt
routine, to indicate to main() that the interrupt has fired. Then use
that flag to qualify doing the test for 'delta'. This "fix" is not wholly
satisfactory, because it prints this result:

[spilz]

Thanks for your work,

I found an other way to "fix" it :
Using #locate to set location of DISPLAY[]

Hope it can help to find the origin of the issue.

But as you said it's not satisfying, it's a way to get around the issue for this little example, but the issue using bootloader is still here and may not be got around for more complex program, like with usb serial :(

[Ttelmah]