| Details |
Message |
|
Read-Only
Author Ian Mellor
Posted 18-May-2012 10:42 GMT
Toolset ARM
|
 Adding bootloader binary to C project
Ian Mellor
Hi all,
I see this is a common problem, I am using uVision 4 with an ARM
7.
I have a bootloader at location 0x0 and application code that is
located at 0x800.
I currently use HEX2BIN and BIN2HEX to merge the files before I can
downloaded them to the target.
However to I would like to debug the application with the bootloader
included as a binary.
Is there a way the linker can add the bootloader binary (or HEX file)
during the build?
I would like to keep the two projects separate.
I'm looking at using bin2c.exe to create a header file with the
bootloader as a const array, but this seems silly when it's the
linkers job to combine object and library files together, why not
also link an external hex or bin file.
Any ideas please.
Thanks,
Ian
|
|
|
Read-Only
Author Tamir Michael
Posted 18-May-2012 12:17 GMT
Toolset ARM
|
 RE: Adding bootloader binary to C project
Tamir Michael
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?
|
|
|
Read-Only
Author Ian Mellor
Posted 18-May-2012 15:10 GMT
Toolset ARM
|
 RE: Adding bootloader binary to C project
Ian Mellor
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
|
|
|
Read-Only
Author scott douglass
Posted 18-May-2012 14:52 GMT
Toolset ARM
|
 RE: Adding bootloader binary to C project
scott douglass
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.
|
|
|
Read-Only
Author Ian Mellor
Posted 18-May-2012 23:53 GMT
Toolset ARM
|
 RE: Adding bootloader binary to C project
Ian Mellor
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
|
|
|
Read-Only
Author Ian Mellor
Posted 18-May-2012 15:26 GMT
Toolset ARM
|
 RE: Adding bootloader binary to C project
Ian Mellor
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
|
|
|
Read-Only
Author Tamir Michael
Posted 18-May-2012 15:35 GMT
Toolset ARM
|
 RE: Adding bootloader binary to C project
Tamir Michael
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.
|
|
|
Read-Only
Author Ian Mellor
Posted 18-May-2012 15:59 GMT
Toolset ARM
|
 RE: Adding bootloader binary to C project
Ian Mellor
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....
|
|
|
Read-Only
Author Tamir Michael
Posted 18-May-2012 16:04 GMT
Toolset ARM
|
 RE: Adding bootloader binary to C project
Tamir Michael
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?
|
|
|
Read-Only
Author Ian Mellor
Posted 18-May-2012 17:09 GMT
Toolset ARM
|
 RE: Adding bootloader binary to C project
Ian Mellor
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?
|
|
|
Read-Only
Author Tamir Michael
Posted 18-May-2012 18:27 GMT
Toolset ARM
|
 RE: Adding bootloader binary to C project
Tamir Michael
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.
|
|
|
Read-Only
Author Ian Mellor
Posted 18-May-2012 19:19 GMT
Toolset ARM
|
 RE: Adding bootloader binary to C project
Ian Mellor
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?
|
|
|
Read-Only
Author Tamir Michael
Posted 18-May-2012 20:41 GMT
Toolset ARM
|
 RE: Adding bootloader binary to C project
Tamir Michael
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...!
|
|
|
Read-Only
Author Ian Mellor
Posted 18-May-2012 23:03 GMT
Toolset ARM
|
 RE: Adding bootloader binary to C project
Ian Mellor
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
|
|
|
Read-Only
Author Hans-Bernhard Broeker
Posted 19-May-2012 00:13 GMT
Toolset ARM
|
 RE: Adding bootloader binary to C project
Hans-Bernhard Broeker
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.
|
|
|
Read-Only
Author Lauris K
Posted 2-Aug-2012 11:55 GMT
Toolset ARM
|
 RE: Adding bootloader binary to C project
Lauris K
Hello everyone,
from what I read this topic is closest to my problem but not quite
what i need, though maybe someone can redirect me in correct way.
how to generate HEX array from bootloader code which I would be
able to insert in to existing code. At the moment working program
have working bootloader saved in HEX array and stored in bootloader
memory area. Thought it was generated with old version of keil. And
now if I try to generate HEX from same working(not yet edited)
bootloader code with newer Keil I get different HEX array and it
isn't working. I'm making HEX array the following way: Code in Kail
generated to *.HEX then using "Hex Workshop v6.6" to import that hex
and export it to *.c
Is it anything i need to do in other way or i'm missing something
or something else?
Program starts as usual at 0x0001 0000
bootloader array at 0x0000 0000
thank you in advance.
|
|
|
Read-Only
Author Ian Mellor
Posted 2-Aug-2012 15:53 GMT
Toolset ARM
|
 RE: Adding bootloader binary to C project
Ian Mellor
Hi Lauris
Not exactly sure what you want to do but here is what I do, not
sure if this will help you...
1. I have a separate project with the bootloader in it (could be
like your old one).
2. I use fromelf.exe (in batch file) to generate a binary file from
the .axf file (if you have the old bootloader hex file you could use
hextobin.exe instead).
3. In my project I have an assembly file that uses the INCBIN
directive.
4. I have a scatter file that places the bootloader.o at 0x00000000
and the rest at 0x00000800
Works a treat for me, I only have to assemble the bootloader
project and run the bin conversion if it changes.
Hope that is of help..good luck
Ian
|
|
|
Read-Only
Author Hans-Bernhard Broeker
Posted 2-Aug-2012 19:34 GMT
Toolset ARM
|
 RE: Adding bootloader binary to C project
Hans-Bernhard Broeker
Thought it was generated with old version of keil. And now if I
try to generate HEX from same working(not yet edited) bootloader code
with newer Keil I get different HEX array and it isn't
working.
Then no, this thread is not dealing with the problem you have,
because you've already applied a solution to the problem discussed
here, and it seems to work.
The problem you have is that your bootloader no longer works if
you re-compile it with newer tools. That's most likely a problem with
your bootloader source code. Whatever that problem is, it would be
better to discuss it in a separate thread, because it is unrelated to
the topic of this one.
|
|