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?
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!
Why dont you people learn to use a search engine?
I used http://www.google.com and got this vip.asus.com/.../view.aspx
Why code with a bug?
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.
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.
i see on google that bootloaders are not good for coding
PLEASE get a encyclopedia and look up just one word "relevance"
Erik