How not to get the reset vector?

 How not to get the reset vector?

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?

 RE: How not to get the reset vector?

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

 RE: How not to get the reset vector?

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

 RE: How not to get the reset vector?

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

Erik

 RE: How not to get the reset vector?

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

 RE: How not to get the reset vector?

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.

Erik

 RE: How not to get the reset vector?

Keils .hex is not "in order"
Damn.

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.

I think I see what you mean. I will play with the CSEG AT 0 part of the startup file.

Thanks.

 RE: How not to get the reset vector?

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

 ever so many kitchen table programmers ....

Keils .hex is not "in order"
Damn.

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

Erik

PS in your scheme there should be no requirement for a sequential .hex file.

 RE: How not to get the reset vector?

http://www.keil.com/support/docs/143.htm

 fine, but not so fine

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

Erik

 yes, but with one provesow

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.

 RE: yes, but with one provesow

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.

Erik

 RE: yes, but with one provesow

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.

 Nonsense!

"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!

 RE: Nonsense!

Why dont you people learn to use a search engine?

I used http://www.google.com and got this http://vip.asus.com/forum/view.aspx?board_id=1&model=A8N32-SLI+Deluxe&id=20060712063248139&page=1

Why code with a bug?

 RE: Nonsense!

sit down, get yourself a Martini, and take of your helmet. if it says "PC" on it, you'll know why that software is wrong.

 RE: yes, but with one provesow

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!

 RE: yes, but with one provesow

A single user have _potentially_ failed to upgrade the BIOS of his PC (which is _not_ an embedded unit) and _may_ at the same time either have managed to botch the update (because of bugs in the BIOS or errors by the user) or may have found an error in the new BIOS.

So what in the world has that thread with a boot loader to do? A lot of BIOS updates are not using a boot loader (if we ignore the fact that a BIOS in itself is a boot loader). Most PC write the message "don't break the power or turn off the machine while the update is in progress". Why? Because they normally replace _everything_ and do not have a static boot loader remaining. If the machine reboots - it will jump straight into a totally erased flash, or into a partially updated application. Many brand name motherboard manufacturers sells their boards with magic "safety features" such as dual BIOSes or other nifties, but in reality that magic feature is a boot loader - either really stupid (such as one that can only drag a BIOS image from a floppy) or smart enough that it looks more or less like the normal BIOS.

The PC originally didn't ahve room for a boot loader, so the manufacturers either took a chance, or charged extra for "premium" motherboards with bank-switched memory to fit a boot loader. Today, they have access to huge amounts of flash, but still like to sell their boot loaders as "premium" features. That might be the right decision, as long as people think it is a premium feature and pays for it.

In the embedded world, there are no end-user interfaces and the target price is so low that you can't handle any support calls. So you really have to have a bomb-proof upgrade path from day one. A correctly written boot loader is a requirement for many companies. Some even ships their products without working software. They start deliveries with a working boot loader and an early alpha application and expect to implement the last features and make the application working before the units are available in the outles.

With a real boot loader, you always have enough code remaining in your unit that you - after a power loss - can pick up the pieces. Either continuing to copy scratch data or to wait for a new application from some communication channel. With an intelligent master to request the firmware from - or room for two applications - a boot loader represents an almost zero-support solution.

The one big issue with a boot loader is that you must supply it with working applications. Pseudo-working applications can result in huge problems. If the boot loader thinks the application is working, and the end user doesn't have a button to force an update (or if the pseudo-working application was responsible for the transfer of a new binary) then you can have a good boot loader but still have a dead unit. But that is a case of bad testing - not an argument for saying that boot loaders doesn't work.

You can not start making claims until you have enough knowledge to understand what you are reading, and can figure out if what you are reading is significant or not. A huge number of gadgets around you have boot loaders - it's just that you do not know about it, because the boot loader works, so you will not see it. You connect your gadget to a USB port on your PC, and you press 'update', and magically everything works. Or sometimes the update is fully automatic and you don't even get a confirmation question.

But what makes a boot loader do what it should is a developer who knows what to do - just the same requirement as for a "normal" program. You must know what to do, and how to do it - if not, the boot loader will fail. Not because it is a boot loader, but because you as a developer wasn't good enough to do it properly. Always separate concept from implementation. A broken implementation does not imply a broken concept.

 i see on google

i see on google that bootloaders are not good for coding

PLEASE get a encyclopedia and look up just one word "relevance"

Erik