USB Bootloader, usign absolute jump?

[Pekotte]

Hello everyone,
I already ask in Microchip without answer, so if you couldn't answer me you can save your time and skip it

I'd like to know if someone was successful programming your own program using a absolute jump to the bootloader.
What I'm doing is, I've got the bootloader and my own program and I'm trying to program both with the ICD3. First I'm programming the bootloader and second my own program, which I'm using the same linker but protecting the bootloader memory space. Even I configure the ICD3 for not erase before to program the second one.
What I'm trying to do is keep safe the bootloader memory space and then after when I'm in my program press a button (touch sense) and then start the bootloader routine. So after reset, It'll always go to user main and then if the touch sense button is press go to bootloader.
Am I doing something wrong?

P.S.: I tried to check the touch sense button in the main of the bootloader, but I couldn't initialise there.

[Olin Lathrop]

There are many was to architect the overall firmware to include a bootloader. What you seem to be doing is reserving a fixed memory region for your bootloader. That's usually how it's done.

The bootloader and main firmware would be built separately, each with a linker file disallowing the program memory address range of the other. It's not clear you are doing this. This is important since you don't want the bootloader to inadvertantly be linked to routines in the main app, and vice versa.

You'd then only externally program the part with the bootloader, and use that to get the main app image into memory, or you combine the HEX files to make a combined HEX file that contains both the bootloader and initial version of the main app.

Your question is otherwise somewhat incoherent, especially when you're babbling on about the ICD3, so I'm not sure what exactly you are doing. The architecture of the bootloader is usually dictated by what circumstances or user actions should triggering uploading a new app, when the system should run the new app, how it decides the new app image is valid, and what it's supposed to do if it's invalid.

A better answer will require a more cohernt question.

[PhilB]

Pekotte,

You haven't given many details of your programs. Like what PIC you are using etc.
However, can I just give you a few pointers based on my experiences?
First, read all the Microchip application notes if you haven't already. they give many useful pointers.
The way I do a bootloader is to put in in the lowest part of memory and let it 'own' the reset and interrupt vectors at the bottom of memory. So a reset jumps to the bootloader. It looks for a valid device on the USB and uses it if present. If not, it times out - 1 or 2 seconds perhaps, then jumps to the application code at a fixed address where the application reset and interrupt vectors are stored. The bootloader interrupt vectors just point to the application interrupt vectors, so apart from a small delay they operate as normal. You have to set the linker files to sort all this out.
To re-enter the bootloader from the application, simply do a software reset. Perhaps set some flags to pass on instructions.
All this is shown in the Microchip application notes.
To debug, use MPLAB X. You can debug both bootloader and application together using 'Loadables'. With the bootloader as the main project, add the application project as a Loadable in the 'Projects' pane on the left. You will find that MPLAB X will compile and load both projects and you can debug both.
Hope this helps,

Regards,

Phil

[Pekotte]

I'm sorry guys,
I completely forgot that I wrote this question in this forum, first of all thank you for your answers.

Olin Lathrop:
You were completely right, I was in a big mistake to think that I could program both app in the same time. Finally I realised and I could fix that part, thank you for your help even when I couldn't make my question very well.

PhilB:
Good ideas, what I finally did was entry directly to the "BootMain" and after 3 seconds (if there isn't USB activity after the reset) go to "main". And thank you for the MPLAB X information, it'll be my next step.

Now the USB Bootloader is programming the PIC well (erasing/programming/verify process is ok), even I can run my app. But (there is always a "but", hehehe), now the interrupts routine aren't working. My first think was to check the program memory just in case I was erasing any vector, but this isn't the case, any suggestions?

P.S: I had to modify the file "c018i.c" and include it in my app manually because the original was writing the _entry tag with a jump to _startup in 0x0000 position.
MPLAB IDE v8.92
PIC18F97J94
C18

[Pekotte]

Hi guys,

From the last post I did some progress, thanks to Phil's tip (using MPLAB X) I was able to find some errors that I could fix and it's almost done. The problem now is that the system is very slow (I mean the display refreshed around 200ms and now it's above 20sec) and the configurations bits are the same in my app and in the bootloader.

I'm toggle a output pin in the first line of my interrupt routine to check the speed, and when I program my app no using the bootloader this pin toggle every 20us, now programming with the bootloader it's every 2,5ms.

Any ideas? Thank you in advance

EDIT: A question, the bootloader modify linker has a write buffer "DATABANK NAME=writebuf START=0x600 END=0x7FF //Big 512 byte buffer for holding an erase page worth of flash contents", Should I keep that databank protected in my app's linker?

[PhilB]

Hi Pekotte,
You don't need to keep the RAM that is used by the bootloader protected in the application. The two programs are entirely separate.
I don't know why your program should slow down. It's maybe a stupid question (but I'll ask it anyway), do you know what frequency your clock is running at? I have had a similar problem where the processor was running off its internal oscillator and not the external crystal. Worth a check perhaps?
There will be some added latency due to redirection from the bootloader interrupt vector, but it should be minimal.
Another potential slowing down is if the code jumps to a blank area of flash, then runs through it executing NOPs until it hits some real code.
Regards,
Phil

[Pekotte]

Hi Phil,

First of all I would like to say what I learned in the Embedded World is that there isn't stupid question, because there is often a small solution for a big problem. After that, we come back to bootloader.
I changed my app for:

void main (void)
{
TRISLbits.TRISL5 = 0; // Output
while (1) { LATLbits.LATL5 = !LATLbits.LATL5; }
}

So I think we can eliminate the possibility of jumps to blank area of flash (anyway I checked executing step by step for a while). What I've got now is a signal of frec = 21kHz when I program my app with the bootloader and a signal of frec = 2,67MHz when I program my app with ICD3:

FREC(boot) = 21kHz --> 21kHz*2 = 42kHz (for each instruction, 2 instruction for 1 period)) --> 42kHz*4 (The processor clock source is divided by four to produce the internal instruction cycle clock) --> 16,8kHz
FREC(icd3) = 2,67MHz --> 2,67MHz*2 = 5,34MHz (for each instruction, 2 instruction for 1 period) --> 5,34MHz*4 (The processor clock source is divided by four to produce the internal instruction cycle clock) --> 21,36MHz.

I'm not sure if those calculations are right, but we can check the huge difference. And I really don't understand the third option (latency from the bootloader interrupt vector) but if you say that the impact should be minimal, I won't be worry about that now.

I hope not be a pain, but this is the last thing I need to finish for close a project, what I started 6 months ago (it should be tested and delivered no after 3 months, if it's before much better and probably the customer will be more happy, hahaha) and I'm really out of ideas .

Regards

[PhilB]

Pekotte,
What I was meaning was are you sure that the oscillator is running from your external crystal? This is usually set by the configuration pragmas that are in your code somewhere, probably in main.c. Usually the bootloader does not overwrite the configuration bits, whereas an ICD3 will.
To me it looks like your bootloader code is running off an internal clock, and the application programmed with the ICD3 is running off a crystal.
Regards,
Phil

[Pekotte]

Phil,

I don't have any external oscillator or crystal, I'm using the fast internal oscillator. I'll copy the configurations bits about the internal clock, maybe you can find the problem.

#pragma config FOSC = FRCPLL // Internal Oscillator (Fast RC Oscillator with PLL module (FRCPLL))
#pragma config CLKOEN = OFF // Clock Out Enable Bit (CLKO output disabled on the RA6 pin)
#pragma config IESO = OFF // Internal External Oscillator Switch Over Mode (Disabled)
#pragma config PLLDIV = NODIV // PLL Frequency Multiplier Select bits (96 MHz PLL selected; No divide - Oscillator used directly (4 MHz input))
#pragma config POSCMD = NONE // Primary Oscillator Select (Primary oscillator disabled)

Just to remind, I'm using exactly the same configurations bits for all these projects.

EDIT: I checked the clock (changing CLKOEN = ON and testing RA6) and is CLK(boot) = 125kHz and CLK(icd3) = 16MHz, I think this is helpful, now we know the problem is something is changing the clock, now I need to know what and where.

Regards

[PhilB]

Pekotte,
I don't know what PIC you're using - a PIC18 of some sort I guess. Is your bootloader erasing the top-most block of memory? Because that's where the configuration bits are stored on some PICs. Maybe that's what is happening. It has to be something that is different from one programming method to the other - and the configuration bits are potentially treated differently. Can you read them back out in the two cases and check that they are the same?
Regards,
Phil