Jump to content
wally

Help In Building A Bootloader

Recommended Posts

Hello,

 

I'm starting to develop an USB bootloader and I've seen that i can build a library and force it's memory location using the -rb <address> linker option.

 

The problem is that I need to include the pic18F2455.h file because the USB needs the definition of all the registers of the chip. How can I do that? In the "target" combo box I can only select PIC18 or PIC16, and if I try to manually include pic18F2455.h I get a redefinition error on some constants.

 

Which is the correct way to do that?

 

And is this the correct way to do what I need? the bootloader i mean?

 

Thank you,

 

Walter

Share this post


Link to post
Share on other sites

Wally,

 

I'm starting to develop an USB bootloader
Sound interesting ;)

 

and I've seen that i can build a library and force it's memory location using the -rb <address> linker option
If you load your bootloader low, then you don't need to use -rb.

You will then need to use -rb in programs you write to download to the device that contains the bootloader as these must start at a different address to avoid the bootloader (I hope that makes sense).

 

The problem is that I need to include the pic18F2455.h file because the USB needs the definition of all the registers of the chip. How can I do that? In the "target" combo box I can only select PIC18 or PIC16, and if I try to manually include pic18F2455.h I get a redefinition error on some constants.

 

Which is the correct way to do that?

You need to drop the inclusion of <system.h> when building libraries.

Instead include <boostc.h> for the general things and include <pic18F2455.h> (in your case) for the device specific things.

 

And is this the correct way to do what I need? the bootloader i mean?
Sounds like you are going in the right direction.

 

Regards

Dave

Share this post


Link to post
Share on other sites

Dave,

 

Wally,

 

You need to drop the inclusion of <system.h> when building libraries.

Instead include <boostc.h> for the general things and include <pic18F2455.h> (in your case)  for the device specific things.

 

I tried with:

 

//#include <system.h>
#include <boostc.h>
#include <pic18F2455.h>
//#include <icd2.h>

#include "USBFirmware.h"
#include "usb_defs.h"
#include "USBDescriptor.h"

 

but what I get from the compiler is:

 

Building...
BoostC Optimizing C Compiler Version 6.35 (for PIC18 architecture)
http://www.sourceboost.com
Copyright(C) 2004-2006 Pavel Baranov
Copyright(C) 2004-2006 David Hobday

...
...

USBFirmware.c
C:\Programmi\SourceBoost\include\PIC18F8720.h(690): Illegal redefinition of symbol: C2OUT
C:\Programmi\SourceBoost\include\PIC18F8720.h(693): Illegal redefinition of symbol: C1OUT
C:\Programmi\SourceBoost\include\PIC18F8720.h(987): Illegal redefinition of symbol: _BOR_OFF_2L
C:\Programmi\SourceBoost\include\PIC18F8720.h(998): Illegal redefinition of symbol: _WDTPS_128_2H
C:\Programmi\SourceBoost\include\PIC18F8720.h(999): Illegal redefinition of symbol: _WDTPS_64_2H
C:\Programmi\SourceBoost\include\PIC18F8720.h(1000): Illegal redefinition of symbol: _WDTPS_32_2H
C:\Programmi\SourceBoost\include\PIC18F8720.h(1001): Illegal redefinition of symbol: _WDTPS_16_2H
C:\Programmi\SourceBoost\include\PIC18F8720.h(1002): Illegal redefinition of symbol: _WDTPS_8_2H
C:\Programmi\SourceBoost\include\PIC18F8720.h(1003): Illegal redefinition of symbol: _WDTPS_4_2H
C:\Programmi\SourceBoost\include\PIC18F8720.h(1004): Illegal redefinition of symbol: _WDTPS_2_2H
C:\Programmi\SourceBoost\include\PIC18F8720.h(1005): Illegal redefinition of symbol: _WDTPS_1_2H

11 errors detected
USBBootloader.c
Error: preprocessing error

failure
Exit code was 1.
Removing target: USBFirmware.obj
Failed to locate output file 'USBFirmware.obj'
Done

 

and I really don't understand why I'm getting an error in the inclusion of PIC18F8720.h that I'm NOT including. Is this depending on the fact that I'm building a library?

 

Thank you,

 

Wally

Failed

Share this post


Link to post
Share on other sites

Wally,

 

The follow code compiles for PIC18 as a library.

#include <boostc.h>
#include <pic18F2455.h>

void foo()
{

}

Maybe you include 18F8720 headers in your other header files?

 

Regards

Dave

Share this post


Link to post
Share on other sites

Dave,

Maybe you include 18F8720 headers in your other header files?

 

unfortunatelly no... I'm not including it. I have several files compiling in my project, but noone is including 18F8720. The bootloader project is a cutoff from a previous project correctly compiling, and it is compiling correctly if I build it as a standard executable and using system.h as the main include. Only if I switch to library and replace the include with boostc.h I get this error.

 

Regards,

 

Walter

Share this post


Link to post
Share on other sites

Wally,

 

unfortunatelly no... I'm not including it. I have several files compiling in my project, but noone is including 18F8720. The bootloader project is a cutoff from a previous project correctly compiling, and it is compiling correctly if I build it as a standard executable and using system.h as the main include. Only if I switch to library and replace the include with boostc.h I get this error.
When you switch to option output type to library, the compiler actually still has a default target device set - PIC18F8720.

 

Having the default set does nothing other than define a symbol _PIC18F8720, so its pretty harmless.

But if system.h is included and finds _PIC18F8720 defined, then it includes all the PIC18F8720.h file.

 

So I suspect somewhere in the code #include<system.h> is present.

 

Regards

Dave

Share this post


Link to post
Share on other sites

Finally I've found my stupid mistake. I still had one file including system.h, so I get a redefinition somewhere. The strange thing is that it was redefining something including the header for a processor I'm not using. May be that depends on the fact that including system.h that definition check for the current processor ends as default in 18F8720?

 

Ok, so that's now solved.

 

I have now my pritty library that creates an HID device that I want to use to load a new firmware. How must I proceed to relocate it somewhere? I tryed with "-rb 0x2000" option in the linker field while building the library and then I added the library to a test project that simply jumps to one of the methods of the library. The result is that all works and the jump is performed correctly, but taking a look to the memory in MPLAB I can see that the library code is not starting at address 0x2000 as i was supposing. All the code is contiguous as normally happens without relocation.

 

Any suggestion?

 

Thank you,

 

Walter

Share this post


Link to post
Share on other sites

Wally,

 

have now my pritty library that creates an HID device that I want to use to load a new firmware. How must I proceed to relocate it somewhere? I tryed with "-rb 0x2000" option in the linker field while building the library and then I added the library to a test project that simply jumps to one of the methods of the library. The result is that all works and the jump is performed correctly, but taking a look to the memory in MPLAB I can see that the library code is not starting at address 0x2000 as i was supposing. All the code is contiguous as normally happens without relocation.
-rb doesn't work the way you think its does.

-rb causes the whole final code to be relocated.

If you create a library -rb does nothing, as the code is not being placed in memory.

 

When writing a boot loader, it is normally a separate program from the program you will download using its.

 

So think of them as two separate applications, build them independantly.

 

The bootloader is normally downloaded only once, using a device programming of some description or ICD interface.

 

The application program is downloaded (using the bootloader) many times as the application is developed.

 

Sorry I didn't think about that earlier - you don't need to make your bootloader a library!

 

Regards

Dave

Share this post


Link to post
Share on other sites
So think of them as two separate applications, build them independantly.

 

The bootloader is normally downloaded only once, using a device programming of some description or ICD interface.

 

The application program is downloaded (using the bootloader) many times as the application is developed.

 

Sorry I didn't think about that earlier - you don't need to make your bootloader a library!

 

Ok, so I'll have two separate applications. Perfect. This point is now clear :D

 

Let say that I have the bootloader application that I want to be in low memory (as normal), and the main applicaztion that I want to load in a specific memory area, 0x2000 as an example. I think that i must build the main application with the -rb 0x2000 option, right? Now the "main" procedure of the main application will be shifted by 0x2000 bytes. How can I reach it from the bootloader? And what about the interrupt routines in that main application? Theese will also be shifted in "high" memory. How do you suggest to handle that?

 

Thank you,

 

Walter

Edited by wally

Share this post


Link to post
Share on other sites

Wally,

 

Let say that I have the bootloader application that I want to be in low memory (as normal), and the main applicaztion that I want to load in a specific memory area, 0x2000 as an example. I think that i must build the main application with the -rb 0x2000 option, right?
Correct
Now the "main" procedure of the main application will be shifted by 0x2000 bytes.

How can I reach it from the bootloader? And what about the interrupt routines in that main application? Theese will also be shifted in "high" memory. How do you suggest to handle that

To start your application your bootloader will need to jump to 0x2000.

To pass on interrupts, your bootloader will need to jump to 0x2004.

 

Have a look at the BoostC bootloader code on the samples page on how to do this.

http://www.sourceboost.com/Products/BoostC/ExampleCode.html

 

Regards

 

Dave

Share this post


Link to post
Share on other sites
Ok, so I'll have two separate applications. Perfect. This point is now clear :D

 

Walter,

for easily guessable safety reasons (antitampering being one) we do not normally use field bootloaders in most of our advanced automotive and industrial products based on PIC18 and other MCUs. Most of them still use OTP MCUs whenever possible, as per MISRA and OSEK recommendations (not to mention IEC61508, and costing issues).

 

Anyway, for lower safety profile applications I've been often using an homebrewed serial bootloader written in assembly. The code is based on Petr Kolomaznic's one, except for a couple of details.

 

The clever idea behind such bootloader (that resides in the topmost 256 bytes of program memory) is that it doesn't give for granted that a PC terminal or controlling (supervisor) MCU is permanently connected to the PIC.

 

It instead features a timed out loading mode, that jumps to resident user code (if any !) if no activity is present on the serial line within, say, the first 300 ms after power-up. This is a very professional approach for standalone devices.

 

If you want to turn to assembly, you can re-use 80% of the same code, while replacing RS232 with USB handling code. Anyway, it all is really worth a glance, at least.

 

Just my 2€c...

Share this post


Link to post
Share on other sites

Your content will need to be approved by a moderator

Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×