How do I get uvision3 to NOT put any code at the reset vector? i.e. completely leave 0-7FFh alone.
The reason is that I want to build only the application part of my program and exclude the bootloader segment that lives between 0-7FFh. The map file shows that indeed everything in the application is where it should be, except the compiler keeps trying to save me from myself and sticks an LJMP at 0x0000 - which I don't want.
How do I keep the C_STARTUP segment from being part of the build?
Gene; Others are more familiar with the Keil C51, but I remember in the startup.a51 file there is an assembly statement such as CSEG AT 0. If you do not include the startup file, default code for startup is still loaded. Also, on the Target -> Options -> C51 dialog, you can move the interrupt table but you can't move the interrupt vectors. Remember, they are in the device firmware. Moving the interrupt tables only creates a LJMP to the new vector table. Bradford
Thanks Bradford, What I was trying to describe was a way to build *only* the application part of the project (800h-7BFF). I do not want this build to include anything in the area between 0 and 800h - otherwise when the hex file is created, it will contain a byte at 0x0000 and the bootloading program will send the command to erase that block - wiping out the block containing the bootloading code.
(I understand how to move interrupt vectors and remap them)
I've almost got it figured out, with the exception that the compiler (or IDE) is adding an unwanted LJMP instruction at 0x0000 when I look at the map file.
It's either a compiler directive, or something in the IDE I need to know that is putting this instruction there.
(The application part of project does not include a startup file. The bootloader part does.)
I've almost got it figured out, with the exception that the compiler (or IDE) is adding an unwanted LJMP instruction at 0x0000 when I look at the map file. make a renamed copy of startup.a51 and include that in the link line. Then change the CSEG at 0 to where you want the app to start - voila
(I understand how to move interrupt vectors and remap them) and you will get a malfunctioning bootloader if you switch that. You need your bootloader not to use interrupts.
a bootloader than can not handle power interrupts or other unexpected events at ANY time is not worth $0.01
Erik
Alright Erik, that is twice now that you've tried to tell me something I do not understand.
The general plan is: * Place a byte in application space that tells the bootloader which mode to enter - i.e. run bootloader, or run application.
During the application run-time, and command can be sent that instructs the application to modify said byte and execute a reset.
Upon reset, the bootloader sees that the byte has been modified, and enters boot loader mode.
Bootloader mode consists of a command set such as: Erase flash page, Block Read, Block Write, etc.
The data comes from the hex file that contains the application segments only. (because obviously you don't want to modify your bootloader segments.)
The only way I can see to break something with a power failure during a bootloading session is to somehow write the bootloader byte with a don't-enter-bootloader value, and somehow not write one of the application pages.
The plan is to place the bootloader byte in the last page of flash, and require that the pages have to be filled in order. If theere is a power failure, the program will still enter bootloader mode if the page containing the byte is anything other than the don't-enter-bootloader value. (i.e. 0xFF)
As far as the interrupt vectors go, I've simply placed LJMP instructions at their hardware addresses to their new table in the application space. (and told the compiler where they are now)
The bootloader will not use interrupts, but if it did, I know how to get them to share nicely.
The application does not need to be able to update the bootloader segments.
Let me know if this plan has any flaws and how I could do it better.
Thanks Gene
Place a byte in application space that tells the bootloader which mode to enter - i.e. run bootloader, or run application. If that is the only diffrence between boot and app, you are fine re power failures. However, I would place it in the last page of codespace and erase that page to indicate bootload and write the byte when boot is complete
require that the pages have to be filled in order. Keils .hex is not "in order"
as far as starting the app, you NEED startup.a51 and, by the method I described, you can place it anywhere you want and jump to it from whatever zero branches to.
Keils .hex is not "in order" Damn.
I think I see what you mean. I will play with the CSEG AT 0 part of the startup file.
Thanks.
Gene; There is one other thing that clicks in the back of my pea sized brain. At one time Keil FORCED a LJMP to 0x0000 in their default code. The purpose was for the coders that forgot to have a forever while loop of some type in main. After running the code would go off to never never land. Keil added a forced LJMP just in case the forever loop exited. It did not matter if you had a proper loop or not, the code was still added. That is probably the LJMP you are seeing in your map. Bradford
.. are made by i.. eh individuals that did not read the spec for Intel hex before they made their crap.
The result of that is, of course, that utilities have been made that will make a .hex file sequential. Some have been mentioned in this forum.
PS in your scheme there should be no requirement for a sequential .hex file.
http://www.keil.com/support/docs/143.htm
this works if you just want to have the whole kit and kaboodle relocated.
However, in the case of a bootloader you want it located in TWO places.
What I do is use the #pragma noiv and write an assembler module that handles the switching and the app then have ljmps to the actual ISRs spaced by 4 in the beginning of the app space. IT WORKS and the only determinig factor boot/app is one bit (which, of course is located absolute). The 'vector switcher' is, of course, part of the bootloader and can thus jump directly to the bootloaders ISRs
I agree with Thiru09, because when I read this topic, At first I think by my self that great! But when I check the keyword "bootloader" use google search. bootloader: is not good to use. There was one page with details for it in JAVA. So the vector jumping is not an working solution to the problem for him.
bootloader: is not good to use. it is, if done right So the vector jumping is not an working solution to the problem for him. it is, if done right
here again a bunch of i..... have tried something that was way over their head and, instead of working it out, they publish "it is not good".
A bootloader is one of the many 'traps' a runner that has not learned to crawl may see and find simple and then jump into, it is not simple. I could whip up a bootloader in a few minutes and it would if qualified by the means many use work. A bootloader that was functional by a rigid definition would take more thought and time.
i see on google that bootloaders are not good for coding. look at http://www.google.com
The best bootloader is the BOIS with the AMD chips and are reliable.
the last answer is an id.... answer.
"i see on google that bootloaders are not good"
Nonsense! either you're misinterpreting what you found, or what you found is wrong. Can you give a specific reference?
"The best bootloader is the BOIS with the AMD chips"
What "BOIS"? What AMD chips? What nonsense!
you just made a fantastic claim that one of the corner stones of many embedded systems if worthless. please provide fantastic evidence of be silent forever!