Hex2Bin for bootloader

[georpo]

Yes of course.
What I mean by brick the PIC is brick the main application firmware.
Not the bootloader. Sure when the bootloader sees a bad line it can do something. But the main firmware is already corrupt. Maybe if I could have a backup image of the working firmware in the external flash which would need a bigger flash
The idea of having a PIC big enough to have a backup partition is also very good but I am at 98% of a PIC24FJ128GA204.
So, what do you guys do to play safe?
_________________
George.

[georpo]

OK, different approach.
21% of the PIC24FJ128GA204 is firmware and the rest is fonts in "const char" tables.

Can I write the font tables to the pic using programmer and then update only the firmware through the bootloader? This solves everything. The "firmware only" hex can fit in my ext flash.

How can I put the tables in specific region of the PIC memory?
How will I declare the tables in the code for reading?

Thanks!
_________________
George.

[temtronic]

While I don't use that PIC, I'm sure the answers are yes....
Others can guide you as to how it's done but offhand, I'd say that when you program the PIC for the bootloader , you can 'burn' the 'font tables' at the same time( say in high memory ),then protect it ,same as the bootloader.

[georpo]

Yes I am also certain that it can be done.
I guess with some #org statements before the tables.
But where should I locate the tables...???
And are there page boundaries etc?
It is a good idea to program the bootloader and the fonts with the programmer and then have the bootloader download the firmware but I am missing basic knowledge on this...

In the "view->program memory" I could not find anything looking like a lookup table.
_________________
George.

[Ttelmah]

You would have to use a #ORG statement to locate your const values
to a fixed set of locations. Otherwise there is a risk they will move. You would
need to have your code having the #ORG, then loading all these tables only
and then switching the #org back to it's default. Otherwise you risk the
constant tables used to do things like initialise variables making the main
font tables move. Then use a tool like HEXit, to import your hex
file, and only export the parts you want to program.

[georpo]

So, I need a program with the bootloader and far back at the memory my font tables.
The question is how far is far enough?
How long is each table so I can start the next table after the previous?
And then in the actual code how do I access the fonts since they are not in the code?

[temtronic]

OK, remember I don't use that PIC or bootloaders but...generally speaking...

PICs have 'banks' of memory. The size of the bank depends on the PIC family.
Let's say your PIC has 128KB of memory consisting of 4 banks, each 32KB in size. Call them Bank 0,1,2,3.
The bootloader program will always go into bank 0 (lowest address),well probably...
Your 'font tables' should go into bank 3, the 'top' of memory. Now if the table is larger than 32KB, it'd have to go into bank2 AND bank3.
So if table fit into bank 3, then your main() program can be in banks 1 and 2. If the table is in banks 2 and 3, obviously main() can only fill bank1.

You'll have to figure out how large your font table is. One way is to create a small program with it in, then look at the 'disassembled listing', find the table, subtract end address from start address.

As for accessing the tables, the compiler will know their start location...
Keep in mind that when you program the PIC for bootloader and tables, you need to 'protect' them so that when you download 'main()' it doesn't overwrite the bootloader or the font tables.

Hopefully someone using the 24 series PICs can offer help

Jay

[Ttelmah]

The answer is in the line 'the compiler knows'.
Load the symbol file.
For your const variables, it'll show where they are placed in the ROM.
Don't do multiple #ORG's. Just have a single #ORG, and load all the font
tables, then switch the ORG back to default operation.

[georpo]

I thought that the #org is only for the code or table following the #org. also I cannot understand what you mean by
switch the ORG back to default operation.
and how will I use the font tables in the actual code since they are not there?
also I think that if I try to compile the bootloader with the fonts included I will get the out of Rom error because I use #define loader pages 3
_________________
George.

[Ttelmah]

[georpo]

I do not get it but I will study and try.
OK, I will find the total size of all the fonts and calculate the address.

[Ttelmah]

The point is you include them in the application code when you generate
this, Then include then in the same way in the original bootloder code.
The application includes them, but you then omit them from what you
actually send to the bootloaxder. Since they are in the same format,
and the same size the code then merrily talks to the already loaded
version.

[georpo]

OK, now we got something
But I have to define a bit value in LOADER_PAGES so as to fit the fonts. Right?
In that case, the bootloader code will be very big with a huge gap in the middle.
Am I wrong?
_________________
George.

[Ttelmah]

No, you don't include these into the area protected and used by the
bootloader. Yes, you load them, but they are not part of the actual
bootloader.