PIC24EP512GP806 - Bootloader no longer working [FIXED]

[benoitstjean]

Device: PIC24EP512GP806
Compiler 1: 5.116
Compiler 2: IDS 5.071, PCB/D/H/M: 5.026

Hi guys,

Years ago, I had bootloader code that worked fine but I haven't used it in 6-7 years.

Back then, I only needed it when shipping devices to partners for testing which, in the event of a required change, all they had to do was to upload new firmware via TeraTerm without needing a programmer.

The process was simple for me:
1. Uncomment bootloader.h in my main code and recompile;
2. Compile and burn the bootloader to the PIC;
3. Reboot the device in bootloader mode;
4. Drag the main hex file into TeraTerm to upload;
5. Reboot the device and after so many seconds waiting for the bootloader, it would timeout and jump to the main code;

I stopped using it years ago and never touched it again for other reasons.

Today, I'm trying to use it again but when I upload the main program, the device just keeps reloading the bootloader instead of running my code.

I think it might be a memory issue. Over the years my code has grown a lot:

- Compiler 2 (IDE 5.071 / PCD 5.026): Compiles at 95% ROM normally, 96% with bootloader.h;
- Compiler 1 (5.116): Won't compile at all—gives "Out of ROM" error on a function with #separate;

Back when the bootloader last worked, ROM usage was around 92-93% when compiled on Compiler 2.

My theory: Since Compiler 2 is older and compiles at 96% without ERRORS, maybe it's silently overwriting memory that the bootloader needs? Compiler 1 fails with an OUT OF ROM ERROR but not Compiler 2.

Tomorrow I'll try commenting out code to get it compiling on Compiler 1 with the bootloader and see if that fixes it.

But does this make any sense? Could compiling at 96% with Compiler 2 be corrupting bootloader memory?

Thanks,

Ben

[temtronic]

It kinda sounds like the 'bank memory' problem.....functions can't 'jump banks'.have to be 100% within ONE bank.
Others will know.... maybe 'optimize' level can fix this ??

[Ttelmah]

The problem is that the bootloader has to end at an erase boundary. So where
the user code can start goes up in the memory, and the 'size' does not tell
the whole story.....

[benoitstjean]

Pardon my ignorance here, but what does this mean exactly "the bootloader has to end at an erase boundary"? Can this be the cause of the problem?

There's some stuff I know and can do but there's more stuff that is above my head which I don't fully understand.

I'm going through my code at the moment to remove stuff that we deemed was not very useful.



UPDATE:

So I've modified my code by reducing the size of an audio buffer in order to resolve the 5.116 compiler issue and the RAM usage is drastically different between 5.116 and "5.071/5.026" and the ROM is also a bit different:

5.116:
RAM 70%
ROM 98%

5.071/5.026:
RAM 51%
ROM 94%

I presume this is a bug in either of the versions?

Which one should I really trust?

This is the same code compiled under the different versions.


Thanks for your help!

Benoit

[jeremiah]

[benoitstjean]

Hi Jeremiah,

So then if that #org thing may resolve the issue, how do I use this? Do I put this in the bootloader code or my main code? And where?

Sorry, this is one of those things that I've never attempted before and I prefer guidance from someone who knows how to implement it.

Is there anything I can check (e.g. a file) after I compiled that would indicate what you explain? Like some place that would show where the code exceeds the boundary?

Thanks for your time and understanding.

Ben

[benoitstjean]

Little update...

I reached-out to CCS support and they suggested I use

#include <pcd_bootloader.h>
#include <loader_pcd.c>

So that's what I did but the darn thing is still not working.

In the bootloader.lst file, here's what I have:

First line:

00000: GOTO A56


At A56:

.................... void main(void)
*
00A56: MOV #7F80,W15



Then when the code is uploaded through the bootloader, device restarted and bootloader is skipped through ESC, it jumps to application() which appears like this in the .LST:

.................... application();
00C1E: CALL 1000


In my code, just before application() is called, I display "[Starting device]" and when the MCU reboots and skips the bootloader to load the real code, I see [Starting device] but that's it, it just sits there doing nothing.


In my firmware that I have just updated, in its .LST file, the very first line 1000 is the following:

01000: GOTO 4E660


And at line 4E660, I have the following:

.................... void main()
*
4E660: MOV #C800,W15



So to me, this appears to be logical, right?


In CCS's loader_pcd.c that was recommended by CCS support, at the end after BootLoaderPutc(XON);, I added fprintf( MONITOR_SERIAL, "\n\rUplaoded successfully" ); but this is the problem - that line is never displayed and that line is followed by a cpu_reset() and that line is not executed.

I know for a fact that the code is uploaded because initially, I used CCS's CCS Load application to erase the PIC. Then, I read it back to confirm it was erased. Then I programmed the bootloader and rebooted in bootloader mode. I then uploaded the code by sending the hex file to TeraTerm and at the end, although I don't get the "Uploaded successfully", I re-opened CCS Load and re-read the contents of the PIC and the firmware appears to be there.

Any thoughts?

Ben

[benoitstjean]

My mind is boggled.

Two problems:


1) Firmware code with bootloader executes even without bootloader
2) Bootloader not working


For simplicity, bootloader code refers to CCS's native bootloader code that I program with the ICD-U64 programmer and firmware refers to my code that makes use of the bootloader code to get programmed through Tera Term and a USB port. This is how I used to do it 6-7 years back and always worked.

So bear with me please, there are things that are above my level of understanding.


PROBLEM 1) FIRMWARE RUNNING EVEN WITH BOOTLOADER COMPILED:

I have the simplest of the apps to load on my PIC. All it does is display "Ready" over a serial port to my Tera Term console.

If I compile "normally" and upload to the PIC the ICD-U64, it works as expected.

But if I compile with pcd_bootloader.h included, I was under the impression that that fiirmware would not run when programmed using the ICD-U64 as it expects to start only when the bootloader is installed.... but it does start. So is it normal that if I compile the firmware with pcd_bootloader.h and program using the ICD-U64, the code will run normally? If yes, then so be it. Otherwise, then something is wrong which might explain #2 below.



PROBLEM 2) BOOTLOADER NOT WORKING:

So now I'm trying to figure-out why the bootloader is not working as I expect it to work like it used to.

As far as I can tell, in the past, all I had to do to to make use of the bootloader was to include the bootloader.h file (pcd_bootloader.h as recommended by CCS) in my firmware then recompile.

To upload the file via the bootloader using Tera Term:

1) I would first program the actual bootloader hex file onto my PIC with the ICD-U64;
2) Reboot the PIC in bootloader mode;
3) I would then drag and drop the newly compiled firmware HEX file (compiled with bootloader.h) to the Tera Term window and that's it;

But it's not working. So I have a very simple test application below that exhibits both problems in #1 and #2.


TestCode.c:

[benoitstjean]

Well well well...

In TeraTerm, under SETUP -> TERMINAL -> NEW LINE -> TRANSMIT was set to CR+LF and I changed it to CR and it fixed the problem.

I knew I wasn't crazy.

I will make sure to document this.

Cheers.

Ben

[temtronic]

You're not crazy Ben, but I bet you have a few more gray hairs now !
I'm super happy you FOUND the 'gremlin' !