Pic18F87J94 bootloader. Downloaded firmware doesn't work.

[isgoy]

Hello

I have a firmware that works with a Pic18F87j94 and compiler version 5.025.
I am trying to put a bootloader and I use the CCS usb bootloader example.
I have modified the example putting my project fuses.
It works correctly and it is detected by computer and siow.exe software.
I compile the main firmware including usb_bootloader.h library.
I dowload the firmware into the pic with siow.exe software.
The problem is that now the firmware doesn't run correctly. I have checked interrupts and they are correct. It seems that it doesn't read correctly the input ports.
Any idea?

Thanks

[PCM programmer]

See this recent thread about the bootloader and #fuses:
http://www.ccsinfo.com/forum/viewtopic.php?t=57257

[isgoy]

Hello

I have tried your solution. It was actived IOL1WAY fuse. I have desactived but I have still the problem.

In mains program fuses I have put

[Ttelmah]

The #build line you show is fundamentally 'wrong'. The PIC18F87J94, does not support a software stack, so you can't expand it with a:

#build(stack=1024)


This option only applies for chips like PIC24/30's, which use the stack for variables, and not just return addresses and have a software stack pointer.
The option is _not_ in the PCH manual. Only in PCD.

Now you show your start of your main, but not whether you are building this to run with a bootloader?. You do realise that the main code has to be built 'offset' to load above the bootloader, if it is going to work?.
So you build the main with #include <bootloader.h> to provide this relocation, while the bootloader builds with:

[isgoy]

If I download the firmware without bootloader in the pic it runs ok with all the original fuses.
I tried to disable
#use fast_io(ALL)
and in this case it also runs ok

Then I make the bootloader firmware:
I have used "ex_usb_bootloader.c" example. I only have put my project fuses in "ex_usb_common.h" file (the same used in original code)

[temtronic]

OK, I don't use that PIC or bootloader so just a comment.

1) when configuring ports using set_tris... and fast_io....) I'd do that first THEN output_xxx. You've got it the other way round, which may affect your external devices. When using 'standard_io(), the compiler configures the port everytime before you access it.

2) you've got #case enabled so perhaps there's something (like a variable or function) that is not working as expected ?

3) Normally you don't 'comment out' fuses, you either code:
#fuse fusenumberone
or
#fuse nofusenumberone

If you comment out a fuse, the compiler will probably code for what IT considers to be the default value, which may not be what you want !
I have ALL the fuses, one per line in a PICtype.fuz file and #include to access it. It allows me to have a good KNOWN set of fuses and cleans up the main() program visually.

Maybe something I offer will help.
Jay

[Ttelmah]

One other comment.

You have ports using:

port_d_pullups(TRUE); //Resistencias de pull-up en puerto D ***c

Are you sure this is the right syntax for your chip?.

A lot of chips require you to set the pullups on a 'per pin' basis.

So:

port_d_pullups(0xFF); //Resistencias de pull-up en puerto D ***c

If your chip supports per pin settings, 'TRUE, will only be enabling the pull up on the bottom pin...

UPDATE.................

Have just checked the data sheet, and on this chip the pullups are on a 'per port' basis, so 'TRUE' will enable them all. One less thing to worry about.

Fuses by default always sit in their 'erased' state. So what a fuse goes to if you don't set it, depends on what the erased setting gives.

Realistically, the 'obvious' thing is that something about the settings used in the bootloader, is preventing some part of the hardware from initialising correctly. Something like a pin driven to a level, before the 'initialisation' code present in the 'main', which then results in a chip not initialising as expected. You need to think how all pins are driven during the bootloader phase. Honestly probably the best thing is to leave everything set as it is at 'boot', rather than making any settings in the bootloader. The bootloader need do nothing except read it's trigger pin (input is the default state for all pins), and should initialise nothing unless it is asked to operate. Even things like the USB init should not be called unless it is going to execute.

[isgoy]

Hello

Thank you very much for your time and suggestions

I have tried all of them without good results (standard_io, fast_io, fixed_io, fuses, pull-up values...)

In bootloader now I don't configure ports. I read only the push buttom to enter in bootloader mode.

I have minimized the code and in a while(1) bucle I active some leds and 7-segment display. It works but if I enable all the port reading code, leds start blinking. It is only when active all of them. Not for active some particular. I try to desactive one or other and it works. Only with all of them

[Ttelmah]

Do a really basic test.

Simple main, that toggles a pin at perhaps 1 second intervals.
Choose a pin that can work with your hardware.

Compile this to load with the bootloader.

Load it.

Does the pin toggle?. At the right rate?.

I must admit I'd still suspicious that your 'main' code is not correctly being loaded by your bootloader. Or that the bootloader is not correctly jumping to the main code.

[temtronic]

Have to agree with Mr. T and do a basic test like he says.
What is confusing is how you say your main program worked 100% when 'burned' into the PIC yet fails when 'bootloaded' into the PIC.

As long as ALL the fuses are the same for the bootloader and main program and enough room is allowed for main to be loaded, I can't see why it doesn't work.

Also, pretty sure I saw you had enabled the 'PROTECT' fuse. While it shouldn't be the cause, it should be changed to NOPROTECT until the product is ready to leave the door( IE sold).

[isgoy]

Yes. This is what I have done.
I have left one timer interrupt and it actives a flag every one second to increment a counter. With this counter I switch on some leds sequentially. Also I active a 7-segment display. I can see messages in it.
When I enable the code to read inputs then I still can see the display message but leds start blinking. This leds are connected to PORTA.
It is very strange.

I have left USB initialization USB_Init();
perhaps I can test if I can run the program without it

[isgoy]

Hello

I have put a function like I use in reading ports library and it runs ok, with all of them. I have realised that if I declare the counters used in this library as global it works but if they are local then it fails.
If I don't include a GSM library that I was not using it works. Then I have enabled all the code without this GSM library but fails again. It can't read an external EEPROM. I had to disable it and usb communication. Then sometimes works but not correctly.
It seems that it is a problem with variables in RAM
I have also disable this line:

[Ttelmah]

It has all the symptoms, that you have something in your code that is incorrectly using a pointer, and walking over memory beyond the end of an array. Changes that affect 'where' variables are placed in memory, then affect what gets damaged by this. So if you change variable declarations they move to areas that are not affected....
You need to look at absolutely everything you have written that writes to something using a pointer or an array, and verify that the index being used is legitimate.

[isgoy]

Hello

I have reduced the firmware because it seems that it is a problem with ram variables. I have reduced it to have a minimum firmware where it fails. I have realised that if I declare some arrays the firmware makes something wrong. But without this declarations it runs ok. Then I reduced it to minimal and it also fails.

This is .c file

[Ttelmah]

I must admit I'd be starting to be suspicious about your compiler version. 5.025, is an old compiler, and I do remember there being some issues with large RAM usage back with these early V5 compilers.