To keep it real, you are not talking about the boot loader, you are talking about the flash code which is uploaded to ram. the
bootloader is in the bin, in the flash chips boot block.
Yes/No.
In general microcontroller discussions, the bootloader in general is the piece of code that executes on startup. IT usually
initializes registers and kicks off whatever code is meant to run at start-up.
In certain areas of GM, bootloader is also used for discussions referring to the subroutines that perform the programming
operations.
The code that you send to the module during a reflashing (and reading) procedures includes support for the proper GM Diagnostic
messaging command (i.e. Mode 34/35) as well as the logic to read/write to the EPROM in most cases. While the messaging
specification and the controller has subroutines defined for the reading and writing modes, they are stub routines that do not
really do anything until you load your initial code.
It is not normally overwritten,
This is not entirely correct.
Many of the older PCM/ECU's have a 1 part binary file that is uploaded. Essentially you load everything over again, including
the boot block. This creates a critical window during the reflash routine. If anything happens while the boot block is erased
and before it is replaced, you will brick the PCM.
Additionally, some of the controllers have calibration / "OS" data residing in part of the boot block due to space limitations.
As the 28F400 is a block mode flash chip, you must erase the entire block before rewriting it, this scenario also creates a
critical window.
The more modern controllers have a requirement that you do not overwrite the startup area to ensure that you do not complete
incapacitate the ECU. But, it's just not the bootloader that can "brick" the PCM/ECU.
and so long as it in intact you can still recover the pcm.
Not entirely true.
In addition to the bootloader, the PCM and your reflash routine are also dependent on the VPW / GMLAN communications section of
the code. The code you upload for reflashion AND the bootloader do not have the capability to "talk" on their own. They are
linked to the VPW/GMLAN code on the controller. Even if the bootloader and your code is intact on the controller, if the
communications software is corrupted during your reflash, you *can* be in for some trouble.
Its possible to brick it if you damage the bootloader
It depends. If you damage the bootloader and do not reset the module, you can restart the flash process again. A failed
programming attempt may not be fatal if you restart the flashing sequence before restarting the module.
Additionally, keep in mind that most of the modules will fall into a "Recovery" model by default depending on what the exact
issue was. For instance, if the bootloader is able to restart the module, but it doesn't detect that the operating software is
right, it will fall into a default reprogramming mode. Mode 36 and other programming related command will work, while basic
ones will not (such as read block or request diagnostic information).
Because of this, certain software will say the module is 'dead' when it really isn't. The problem is that the software is
trying to go through the normal set of communication procedures and those will fail. I have unbricked a 'ton' of modules simply
by using a different set of instructions....
Even the 'bricked' modules are relatively easy to fix assuming you know what you're doing. All you have to do is pull the chip
and reflash it on a burner such as an EMP-20. You could also wire up the ICE and repair the flash software that way.
, but all in all the flash process is pretty hardy to power or connection dropouts, even if you are overwriting the os.
It really depends where in the process you are and power issues are the number fear. You should not start a programming event
if voltage is below 11.6V, IMHO. The ECU/PCM will shutdown just north of 11V in most cases. Be sure to turn off your
headlights and other crap when reprogramming as the LAST thing you want is the battery crapping out in the middle. Good
software will check system voltage before starting a flashing event. (at least mine does)
You do not need to supply an algo number for the seed/key.
Really?
Riddle me this.
You connect to a module and request the Seed and it gives you one. HOw do you know which of the 256 algorithms you use to
generate the proper key?
Sure you don't supply the algorithm as part of the mode 27 communications; however, *YOU* need to know it so that you don't have
to brute force 256 different algorithms for a given seed.
After looking at the "code" posted here, it looks like it is specific to the 411 PCM. The algorithms are generally the same for an entire "family" so the "411" code here may work quite universally, etc.
There's a way to know which algorithm you need.
The STN1110 would be a good option, if they support large packets. They were talking about adding the feature, and if they do
then we can give it a shot. Otherwise the interface ealyer in this thread here viewtopic.php?f=4&t=1566&start=50#p19439 would do
it, if anyone were to make up a batch.
I have an interface design and firmware; however, it needs a bit of work, though it will work out of the box....
What I don't have is time to put everything together to build (and maintain) a complete product.
Or there is the avt-852
http://www.avt-hq.com/products.htm#AVT-852 which would do it, do it very well, and support can bus, but
its more expensive, and I know AVT-HQ will sell small batches of boards, but they are the only source and took them off the new
I've sold thousands of AVT boards in the past and they do work. The problem is that they are too expensive.
