I am just learning about Microchips's bootloader capabilites. What is
not clear from any of the documentation I've read is whether the chips
with bootloading capabilities ship with the bootloader firmware
installed. Some posts in this group indicate that you have to add the
firmware yourself with an ICSP, which of course requires a hardware
programmer and the corresponding software.
This may sound like a dumb question, but if that is true, why?? Why
wouldn't Microchip just burn the chips with the bootloader so that all
of us poor developers only need to connect the chip to a serial port
and do an instant download of our application code without requiring a
hardware programmer. Am I missing something here?
One additional note. I read in Microchip's AN581 doc that they supply a
program called Quick Programmer used to program / communicate with a
bootloader. I couldn't find such a product on their web site. Has this
been integrated into their MPLAB?
Thanks for your response
Johann Blake
Reply by Meindert Sprang●December 22, 20052005-12-22
<johannblake@yahoo.com> wrote in message
news:1135238471.275611.20580@g49g2000cwa.googlegroups.com...
> I am just learning about Microchips's bootloader capabilites. What is
> not clear from any of the documentation I've read is whether the chips
> with bootloading capabilities ship with the bootloader firmware
> installed. Some posts in this group indicate that you have to add the
> firmware yourself with an ICSP, which of course requires a hardware
> programmer and the corresponding software.
>
> This may sound like a dumb question, but if that is true, why?? Why
> wouldn't Microchip just burn the chips with the bootloader so that all
> of us poor developers only need to connect the chip to a serial port
> and do an instant download of our application code without requiring a
> hardware programmer. Am I missing something here?
The point you miss is that some don't want a bootloader because it eats
memory. Also when Microchip installs a bootloader, does it meet your
requirements? Maybe you want a simple bootloader to load your programs, but
I would want a more secure bootloader with encryption so that people who get
my images to load, cannot disassemble those images and "steal" my design. So
in short: the requirements for a bootloader can be very different for anyone
and it would be therefore pointless to preload a bootloader.
Meindert
Reply by Andrew M●December 22, 20052005-12-22
It's fair to say that most of the PIC business is either factory programmed or
in-circuit programmed in high quantities. There is no reason to instal a bootloader
for either of these situations. These guys sell a billion PICs a year, folks...
I know of companies who program their own bootloaders into PICs but they are for
specific communications or security requirements.
-Andrew M
"Meindert Sprang" <mhsprang@NOcustomSPAMware.nl> wrote in message
news:11qkrbm85844g7e@corp.supernews.com...
> <johannblake@yahoo.com> wrote in message
> news:1135238471.275611.20580@g49g2000cwa.googlegroups.com...
>> I am just learning about Microchips's bootloader capabilites. What is
>> not clear from any of the documentation I've read is whether the chips
>> with bootloading capabilities ship with the bootloader firmware
>> installed. Some posts in this group indicate that you have to add the
>> firmware yourself with an ICSP, which of course requires a hardware
>> programmer and the corresponding software.
>>
>> This may sound like a dumb question, but if that is true, why?? Why
>> wouldn't Microchip just burn the chips with the bootloader so that all
>> of us poor developers only need to connect the chip to a serial port
>> and do an instant download of our application code without requiring a
>> hardware programmer. Am I missing something here?
>
> The point you miss is that some don't want a bootloader because it eats
> memory. Also when Microchip installs a bootloader, does it meet your
> requirements? Maybe you want a simple bootloader to load your programs, but
> I would want a more secure bootloader with encryption so that people who get
> my images to load, cannot disassemble those images and "steal" my design. So
> in short: the requirements for a bootloader can be very different for anyone
> and it would be therefore pointless to preload a bootloader.
>
> Meindert
>
>
Reply by ●December 22, 20052005-12-22
Thanks for insight. I wasn't aware that the bootloader was using the
same memory space that my app would use. Too bad that Microchip doesn't
just include a built-in bootloader separate from the memory space used
for applications. This could just be a basic bootloader to
download/upload code or data. They could even allow you to set a
password to avoid the problem that you mentioned.
As I now see it, the point of the bootloader really is meant for after
production purposes. It doesn't appear to be possible to avoid using a
hardware programmer at this stage.
Thanks again
Johann
Reply by Mike Harrison●December 22, 20052005-12-22
On 22 Dec 2005 00:01:11 -0800, johannblake@yahoo.com wrote:
>I am just learning about Microchips's bootloader capabilites. What is
>not clear from any of the documentation I've read is whether the chips
>with bootloading capabilities ship with the bootloader firmware
>installed. Some posts in this group indicate that you have to add the
>firmware yourself with an ICSP, which of course requires a hardware
>programmer and the corresponding software.
>
>This may sound like a dumb question, but if that is true, why?? Why
>wouldn't Microchip just burn the chips with the bootloader so that all
>of us poor developers only need to connect the chip to a serial port
>and do an instant download of our application code without requiring a
>hardware programmer. Am I missing something here?
They can't program it in the factory because everybody's application is different.
Different IO setup requirements, different comms interfaces, speeds & protocols.
It would be a waste to spend money putting code in the chip that is only usefult to a small
proportion of users.
Reply by Thad Smith●December 22, 20052005-12-22
johannblake@yahoo.com wrote:
> Thanks for insight. I wasn't aware that the bootloader was using the
> same memory space that my app would use. Too bad that Microchip doesn't
> just include a built-in bootloader separate from the memory space used
> for applications. This could just be a basic bootloader to
> download/upload code or data. They could even allow you to set a
> password to avoid the problem that you mentioned.
I consider the JTAG download support a bootstrap loader. A lot of
companies provide simple programmers based on this.
The MSP430 has both a JTAG programming interface and a asynchronous
serial bootloader. The async version resides in user space. I have
used it because it requires few pins, but I believe it is a little slower.
--
Thad
Reply by Ian Bell●December 22, 20052005-12-22
Meindert Sprang wrote:
> The point you miss is that some don't want a bootloader because it eats
> memory. Also when Microchip installs a bootloader, does it meet your
> requirements? Maybe you want a simple bootloader to load your programs,
> but I would want a more secure bootloader with encryption so that people
> who get my images to load, cannot disassemble those images and "steal" my
> design. So in short: the requirements for a bootloader can be very
> different for anyone and it would be therefore pointless to preload a
> bootloader.
>
better to use a decent micro like the 8052 variants from Philips. All come
with a built in bootloader in ROM that does not eat into your program
space.
IAn
Reply by Meindert Sprang●December 22, 20052005-12-22
"Ian Bell" <ruffrecords@yahoo.com> wrote in message
news:doep4t$7mq$1@slavica.ukpost.com...
> better to use a decent micro like the 8052 variants from Philips. All come
> with a built in bootloader in ROM that does not eat into your program
> space.
All?
The 87C52 I use doesn't have one....
Meindert
Reply by Stephen●December 22, 20052005-12-22
In article <doep4t$7mq$1@slavica.ukpost.com>, Ian Bell
<ruffrecords@yahoo.com> writes
>Meindert Sprang wrote:
>
>> The point you miss is that some don't want a bootloader because it eats
>> memory. Also when Microchip installs a bootloader, does it meet your
>> requirements? Maybe you want a simple bootloader to load your programs,
>> but I would want a more secure bootloader with encryption so that people
>> who get my images to load, cannot disassemble those images and "steal" my
>> design. So in short: the requirements for a bootloader can be very
>> different for anyone and it would be therefore pointless to preload a
>> bootloader.
>
>better to use a decent micro like the 8052 variants from Philips. All come
>with a built in bootloader in ROM that does not eat into your program
>space.
I wish more microcontrollers would offer built-in ROM bootloaders.
How many products have you ever used or owned that offered flash
updating to the end user (motherboards, modems, satellite/freeview tv
decoders, etc.) that said somewhere in the flash upgrade procedure
instructions something to the effect of "interrupting this process may
permanently damage the product".
I interpret this to mean "we cost-cut the product so much that there is
no ROM bootloader and if you get a power-cut, any form of serious
glitch, crash, or any other type of failure, you might end up with a
dead product that needs to be returned to the factory", which is often
too expensive a repair option. It may only be a small risk, but I don't
want to tell my customer 9000 miles away that the hex file I just sent
him will work but that there is a small chance he'll have to send the
equipment here instead. Protecting a bootloader in a flash boot block
would help, but still isn't guaranteed. Adding an EPROM for this purpose
alone is too expensive.
By contrast, the last two major product developments I have done used
microcontrollers with primitive ROM bootloaders. These allow me to
absolutely guarantee a means by which the end user can recover from a
faulty flash upgrade attempt regardless of what state the contents of
flash are. If I require security or other features I can use the
primitive bootloader to download a complex bootloader and continue from
there to download the full firmware image.
I may only end up using the primitive bootloader as a fail-safe if the
regular upgrade process fails, but at least the option is there, and
effectively "hard-wired" into the chip. The ROM only needs to be
typically a few hundred bytes for a primitive bootloader and typically
an I/O pin to activate it on bootup.
Reply by Rene Tschaggelar●December 22, 20052005-12-22
johannblake@yahoo.com wrote:
> I am just learning about Microchips's bootloader capabilites. What is
> not clear from any of the documentation I've read is whether the chips
> with bootloading capabilities ship with the bootloader firmware
> installed. Some posts in this group indicate that you have to add the
> firmware yourself with an ICSP, which of course requires a hardware
> programmer and the corresponding software.
>
> This may sound like a dumb question, but if that is true, why?? Why
> wouldn't Microchip just burn the chips with the bootloader so that all
> of us poor developers only need to connect the chip to a serial port
> and do an instant download of our application code without requiring a
> hardware programmer. Am I missing something here?
>
> One additional note. I read in Microchip's AN581 doc that they supply a
> program called Quick Programmer used to program / communicate with a
> bootloader. I couldn't find such a product on their web site. Has this
> been integrated into their MPLAB?
There are several ways to communicate with a processor.
Just that it has a UART doesn't mean this is the to be
used communication channel. SPI, external UART, Ethernet
come to my mind. Then when you already
communicate with a processor, then you'd wish the
bootloader to have the same protocol such that it fits
into your application.
Rene
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
Signal Processing Engineer Seeking a DSP Engineer to tackle complex technical challenges. Requires expertise in DSP algorithms, EW, anti-jam, and datalink vulnerability. Qualifications: Bachelor's degree, Secret Clearance, and proficiency in waveform modulation, LPD waveforms, signal detection, MATLAB, algorithm development, RF, data links, and EW systems. The position is on-site in Huntsville, AL and can support candidates at 3+ or 10+ years of experience.