Pic18F87J94 bootloader. Downloaded firmware doesn't work.

[temtronic]

OK I don't use that PIC and ..
Mr. T . may be onto something...

however this caught my eye.
...
unsigned int1 EstadoPuertoPulsador;
unsigned int1 EstadoPuertoPulsadorAnt;
unsigned int1 FlancoBajadaPulsador;
unsigned int1 FlancoSubidaPulsador;
unsigned int1 IncCont100ms;
unsigned int1 IncCont1seg;
unsigned int1 SalSirena;
unsigned int8 NumeroPantalla;

...
uses 7 bits. I would add a 'dummy' 8th bit just to 'tidy' up the use of RAM.
Maybe it doesn't matter, but in the past we've seen 'boundary issues' when bytes don't line up neatly. I assume the compiler would assign those 7 bits to one byte and the listing would show what the compiler did.

That PIC has LOTS of RAM so 'space' shouldn't be the issue, but perhaps the implementation is or the assignements of the RAM themselves.

[isgoy]

Originally I used structures of 8 bits declared in a library to some flags in the code. To reduce them and to don't use this libraries, I have declared this "unsigned int1" variables.
I don't think this could be a problem. If I don't declare big arrays it runs ok. If I do, it fails.

It seems that it is a compiler problem. I will report it to ccs
Thanks!!!

[Ttelmah]

That compiler is over fifty versions out of date....
CCS are hardly going to be interested in an issue that they have probably fixed long ago.
2014 compiler.....

[temtronic]

One way to narrow down this problem is to create a simple program that just reserves a portion of RAM as an array and fill it with data.
Make the array say 64 bytes long, fill and see if it works.
If that works, make it say, 255 bytes long and retest.
Keep increasing and testing until it fails.
If one huge array works, then create 2 arrays and repeat the process.
Your program has 5 or 6, 100 byte arrays and fails ,so really these tests of mine should fail quickly.
If these test programs do NOT fail, it's probably not a compiler/array problem, rather something in your code is causing it to fail.

Jay

[Ttelmah]

There was an issue with structures sometimes being placed into the same RAM as other variables. Fixed about 5.030. A couple of other minor PIC18 memory management issues also that have been fixed since.

[isgoy]

I am talking with CCS. We have analyzed generated LST files and it seems that all is correct.
I have done some test and it fails when the variables are in another bank of RAM different to 0. It seems that it doesn't make correctly the change of the BSR to access them or, it some conditions, it lost BSR value.
If I declare this arrays at the end of the code it runs ok because used variables are in bank 0.
We have analyzed LST file and it seems that it saves BSR when an interrupt appears.
In bootloader is put NOXINST fuse. I have put also in main code but nothing.

One friend has compiled me the code with 5.076 version and it fails.

[Ttelmah]

Try one simple/silly thing.

Declare your arrays as 128 entries each not 100.
I know it'll use more RAM, but see if the problem disappears.

I remember an issue several years ago, where a user was having an array getting corrupted. It did seem to only happen when the array size was a multiple of 100!.

[isgoy]

It also fails with array of 128.

[Ttelmah]

Fair enough.
It was worth the test.

Have you tried the experiment of building the code located at 0x2000, with just the re-vector parts, but no actual bootloader?.

I must admit your problem is 'odd' One person only reported a similar problem in the last few years, and that with a very early V5 compiler. I've built code with KB of RAM in use, and never seen anything causing problems whether loaded with a bootloader or not. Once the code is booted, the bootloader should make no difference at all.

Have you tried with more than one chip?.
One obvious 'difference' with the bootloader used, is that the code will be sitting much higher in the ROM. This is why the test without the bootloader, but with the code still positioned at the higher location is potentially 'informative'. It is possible that the ROM may have a faulty cell, which just happens to be hit when the code it located higher. Adding the arrays does add some extra code to handle these so these may just be triggering a hardware fault....

[isgoy]

I have tried with another pic and it also fails.
It is strange because original whole code uses variables in a lot of blocks of RAM and it doesn't fail

[Ttelmah]

Yes. I must admit to finding myself thinking 'outside the box' on what is actually going on. Thoughts like a ground loop when the bootloader is connected resulting in corrupted writes. Or possibly corrupted execution (are you disconnecting the bootloader connection when testing?).
Seriously too many thousands of pieces of code have been written and used with CCS and the bootloader for there to really be an issue. Hence something else needs to be going wrong. Problem is 'what'?....

[temtronic]

Sounds like it's time to go back to a 'flashing LED' program and see if it works. If so, then allocate say a 64 byte buffer, loop to fill and test. If that works, keep doubling buffer,fill, test, repeat until it does fail.
'something' is weird... your real program works if 'burned' in, the bootloader should be solid,sigh...
Jay

[Ttelmah]

OK

[isgoy]

Thank you Ttlemah.
It doesn't work.
I have to do another test like temtronic says and with your suggestion.
I will say you my conclusions.