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
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
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.
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.
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
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.