Adding bootloader binary to C project

However to I would like to debug the application with the bootloader included as a binary

Why do you need to do that? These are two separate programs so you cannot unless you added the code of the bootloader to the application. HEX files don't contain debug information.
You can merge HEX files by simply removing the last line of one of them and copy-pasting the other instead of that line. Why all trouble?

I'm not saying it's a good idea, but armasm has INCBIN which you can use to get a binary into a section of a .o file and then use scatter loading in armlink to place it somewhere.

Hi Tamir,

It would just make my life a lot easier.
I have 3 devices each with their own code and bootloader.
One device also has the ability to update firmware of another so it carries a piggyback binary as well as its code and bootloader.

I'm not interested in debugging the bootloader, if I need to I'll do that on its own.
So it does not bother me if there is no dis-assembly listing it will normally just jump in to main() eventually.

So unless I'm doing something wrong here every time I want to debug my code I have to change the ROM vectors in the target pod re-assemble and load. If I want to then try out the changes on a target I have to change them back compile merge the two HEX files and download the merged using the uLink. No to mention if changes in the application code push the vectors of the piggyback bin file.

Should be a simple thing to add to a linker and looking of the forum a lot of people use bootloaders.

Or am I going about it the wrong way?

Thanks,

Ian

Hi Tamir,

It would just make my life a lot easier.
I have 3 devices each with their own code and bootloader.
One device also has the ability to update firmware of another so it carries a piggyback binary as well as its code and bootloader.

I'm not interested in debugging the bootloader, if I need to I'll do that on its own.
So it does not bother me if there is no dis-assembly listing it will normally just jump in to main() eventually.

So unless I'm doing something wrong here every time I want to debug my code I have to change the ROM vectors in the target pod re-assemble and load. If I want to then try out the changes on a target I have to change them back compile merge the two HEX files and download the merged using the uLink. No to mention if changes in the application code push the vectors of the piggyback bin file.

Should be a simple thing to add to a linker and looking of the forum a lot of people use bootloaders.

Or am I going about it the wrong way?

Thanks,

Ian

Could you please explain clearly what it is that your are trying to do, and what problem you are trying to solve. Slow, step by step. I don't fully understand you yet.

1. I have a bootloader located starting at 0x0 pre-built.
2. My application code starts at 0x800 and is a C project.
3. I want to be able to load in the pre-compiled bootloader when I'm building the application.
4. So that I can debug the application (not the bootloader) with the bootloader in place.
5. I do not want to change the target vectors all the time.

Hope this is clearer for you....

4. So that I can debug the application (not the bootloader) with the bootloader in place.

Wait a second. If you program your bootloader at 0x0, and program the application at 0x800, starting the debugger for the application gives you what you want, not?

5. I do not want to change the target vectors all the time.

If the application remaps the vectors upon startup (you can force that using macros - see startup file), what is the problem, exactly?

I don't see why you think what I'm doing is so strange?

I want to have the bootloader there and working when I debug.
I don't want to debug the bootloader, I want to debug the application only.
But the application is called through the bootloader and the application can call the bootloader.
So the only way I can do that is somehow add the bootloader binary to the build.
Or is there another way?

I did not think what you are doing is strange, until this:

and the application can call the bootloader.

This is not normal nor recommended, unless you mean that these programs share memory - not code.

It not a problem simply an external command to the application and it resets so invoking the bootloader.

Thanks for the advice, any idea how I can add the bootloader to my build or is it not possible?

I don't understand what your problem is.
Just start the debugger for the application - that will implicitly require the bootloader to execute.

5. I do not want to change the target vectors all the time

I don't understand why not - just place the application at 0x0 then...!

Michael,

I'm sorry you don't understand, I don't understand why you don't understand.
I must be very bad at explaining things our your very bad at understanding things.
I'm just looking for help trying to do something that I feel I need to and it seems from you responses you don't think I should or need to do it. This is based on very little understanding of my requirements.

I'll try one more time to explain....

I would like to debug the application.
I would like to do that with the bootloader there so I can go in and out testing the application as it invokes, or not, the bootloader in a variety of circumstances.
I would like not to have to play with target settings and build macros if I can avoid it (especially with three devices)....you might like to do that but I don't.
I also want to test the piggyback bootloader and I need to include the actual binary file for the target device, it cannot be done by magic it needs to be there with the application.

Do you or anybody else have any ideas that would help me.
Please no negative responses...

Thanks

Ian

Hi Scott,

Thanks for the idea.....I was a very good one!!...and I works a treat.

Here is what I did:

1. Created new file bootloader.s with the following in it:

AREA Bootloader, CODE, READONLY

INCBIN .\\Zone_Pod_Bootloader\obj\PodBootloader.bin

END

This is great because it takes the binary from it's associated bootloader project.

2. Modified the scatter file as follows:

LR_IROM2 0x00000800 0x0001F800 { ; load region size_region ER_IROM2 0x00000800 0x0001F800 { ; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } RW_IRAM1 0x20000000 0x00003F80 { ; RW data efm32_msc.o (+RO) .ANY (+RW +ZI) }
}

LR_IROM1 0x00000000 0x00000800 { ER_IROM1 0x00000000 0x00000800 { ; load address = execution address bootloader.o (+RO) }
}

I have tried it and it works great, I have been able to get the application and the bootloader to work (in different circumstances). I can also step through using the debugger and even single step through the bootloader assembly code (not that I should need to).

I can't thank you enough.
If your even in Ireland give me a shout and I'll buy you a pint!!

Ian

The thing you're overlooked so far is that you can do much more than just loading the application when you start a debug session. That's what the debugger has an "init script" for.

One of many things you can do in there is load additional data (e.g. your bootloader) into the target, before you start the program. You could even go one step further and load the debuggable image of the bootloader, so you would have symbols of both your bootloader and your application available in the same debug session.

The thing you're overlooked so far is that you can do much more than just loading the application when you start a debug session. That's what the debugger has an "init script" for.

One of many things you can do in there is load additional data (e.g. your bootloader) into the target, before you start the program. You could even go one step further and load the debuggable image of the bootloader, so you would have symbols of both your bootloader and your application available in the same debug session.