#import to combine bootloader with application code [SOLVED]

[soonc]

Using Compiler Version: 5.059
PIC24FJ128GA306

Bootloader code and sample application as per CCS Example.

I can program the Bootloader and then using teraterm successfully load the real application.

Now I want to create a combined HEX file for programming with the ICDU64.

Reading this forum I think I need to use: #import

I'd like to #import the bootloader to my application ? as the bootloader should not need change.

In my application code I used this:

#include "pcd_bootloader.h" // copied to local folder

#import (FILE=C:\Source\BootloaderExample\ex_pcd_bootloader.hex, HEX, RANGE=0:LOADER_SIZE)

The error messages are:
Memory not available are requested location.
and File cannot be opened for write.

Or do I use the #import in the bootloader source and import the application. This means of course I'll be compiling both the app and the bl each time. !

Clearly I don't understand this #import directive... any help would be welcome.

[Ttelmah]

The easiest way is honestly either to use MPLAB, and load the two hex files one after the other, then export the hex corresponding to the whole of memory. Some programmers also allow you to load a hex file without erasing, so again you can load the bootloader, and then the main code.

With #import, do the following:

1) Get rid of all fuses in your main. Replace with:

#fuses NONE

2) Then add the line:

#IMPORT (FILE=bootloadername.HEX,HEX)

Immediately after the fuse location etc.. With the name of your bootloader hex file.

3) Obviously make sure you are loading the bootloader.h file to set the build address etc., in the application.

This then imports the bootloader hex file into the application, which then won't complain that they are trying to use the same memory addresses (since you don't set the fuses, and the build is to different addresses).

[soonc]

[Ttelmah]

Normally the error is caused by the fuses (hence my suggestion), since both the imported file, and the application contain fuses.
However the error suggests that your application may not be correctly re-locating itself to work with the bootloader. Are you sure your application build is using the same loader size settings as the bootloader?. Have you tested the application using the bootloader?.
The import _does_ work, if the settings are correct in both files.

[soonc]

[jeremiah]

So I tried this out:

Grabbed pcd_bootloader.h and ex_pcd_bootloader.c

didn't change them, but just compiled to get a ex_pcd_bootloader.hex file

I started a separate project with my own main file, application_main.h and copied the ex_pcd_bootloader.hex file into the same directory. This is my application main:

[soonc]

[Ttelmah]

Good.

The #fuses NONE, will get rid of the warnings about the fuses.

It's silly really. You would think, that if you include the 'import range' (as you do, and I don't), it would stop it complaining about the fuses (since you are not importing these), but it still does moan.

When you think just how large the code is, and then tot up the mSec/write time, it is terrifying just how slow the bootloader can become on larger chips. Just be glad you are not on a '512' version!...

[soonc]

[jeremiah]

Another option to try would be to change your project settings paths to point to where ever your bootloader.hex is (like you would for code in other folders). Then you don't need to specify the path in the import statement (assuming it works).

Also, be wary of using #FUSES NONE with your particular configuration. Your import statement isn't loading the FUSES of the bootloader, so having $FUSES NONE can lead to some odd FUSE settings if your bootloader isn't using the default fuses. You either have to specify the same FUSES in your application or if you use FUSES NONE in your app, then you need to do possibly another IMPORT statement with just the fuses range from the bootloader.hex

Either way, always make sure to do a file compare between the original bootloader.hex and the combined.hex. The only code differences should be between LOADER_END and the FUSES..

FUSES NONE is definitely great when you are loading your app serially, etc.

[soonc]

[jeremiah]

for #use spi and streams you need to use spi_xfer for both reading and writing.

spi_read and spi_write are for when you use setup_spi *instead of* #use spi. Two different methods.

[soonc]

[jeremiah]

Can you post a small compilable example of your application? Just have spi do something in the main. Basically strip out everything but the SPI related code, make sure it still doesn't work. It should be as simple as possible and something we could copy / paste into a file and just compile out of the box.

EDIT: compilable assuming we have the bootloader.hex which we can build using the example file + the fuses/clock you have in the application.

EDIT2: If it works in software but not hardware, one thing to look at is perhaps you are trying to set the pin selects twice without enabling the FUSE that allows that?

[soonc]