|
We have been using the CABLE12 interface cable to program a 68HC12 target for the last year. We use the Cosmic compiler to generate .H12 files which are then downloaded to the Flash and EEPROM (using Cosmic's ZAP) of the MC912 processor on our product. We would like to be able to develop code (and create a .H12 file) in-house and send the .H12 file to a customer who could then re-program the micro on his device with the updated code. What are the minimum/cheapest products (P&E Micro or otherwise) the remote customer would need to re-program his micro? Assume he has a PC with a parallel port and is not interested in doing any debugging. (I guess this process could be considered updating the firmware.) Would the BDM MULTILINK alone be sufficient, or would he also need additional software (e.g., PROG12Z) to download the code? Do you know if there are any other light-weight (without debugging features) software and hardware solutions that would accomplish this? Andrew Heninger |
|
|
Minimum equipment to re-program HC12
Started by ●June 30, 2003
Reply by ●June 30, 20032003-06-30
|
At 10:35 AM 6/30/2003 -0700, you wrote: >What are the minimum/cheapest products (P&E Micro or otherwise) the remote >customer would need to re-program his micro? That's one reason we switched the last couple of projects from the HC912B32 to the D60A. It got rid of the need for the field customer to have ANYTHING except a serial port. [Remember, today's laptops may not even have a serial or parallel port.] To go BDM on something like a B32, in addition to the BDM pod and the programming software, you are also going to need a source of 12 Vdc for Vfp. jmk ----------- James M. Knox TriSoft ph 512-385-0316 1109-A Shady Lane fax 512-366-4331 Austin, Tx 78721 ----------- |
|
|
Reply by ●June 30, 20032003-06-30
|
Sorry, I should have clarified: We are using a MC912DG128A (which
doesn't require an extra Vfp for the EEPROM). In addition to a PC, the customer also has a properly powered HC12. I guess I was interested in my options on the BDM pod and programming software. Thanks. - Andrew At 10:35 AM 6/30/2003 -0700, you wrote: >What are the minimum/cheapest products (P&E Micro or otherwise) the remote >customer would need to re-program his micro? That's one reason we switched the last couple of projects from the HC912B32 to the D60A. It got rid of the need for the field customer to have ANYTHING except a serial port. [Remember, today's laptops may not even have a serial or parallel port.] To go BDM on something like a B32, in addition to the BDM pod and the programming software, you are also going to need a source of 12 Vdc for Vfp. jmk ----------- James M. Knox TriSoft ph 512-385-0316 1109-A Shady Lane fax 512-366-4331 Austin, Tx 78721 ----------- -------------------- ">http://docs.yahoo.com/info/terms/ |
Reply by ●June 30, 20032003-06-30
|
How sophisticated is your customer? If they have "some"
technical knowledge on-board, then any commercial product is probably OK. If not, then the problem is that if you give them complete instructions, and something goes wrong, how are they going to fix it? Also, which device(s) are you supporting? We have a D60A in the field, and Motorola has recently (for us, anyway, we don't ship a lot of these) changed the flash security to add a lock bit that is programmed in a shadow byte in the EEPROM. I forget the details, but the shadow byte is controlled by a byte in RAM, or Flash, or someplace. Sorting through all of this seems to be a 27 step process, with several resets along the way. Our customer is very sophisticated, but I don't know yet if I can hand it off to them or not (especially since I haven't got it working myself, yet.) Unfortunately, the alternative seems to be to write a custom program, and keep it in the boot block. Motorola specifically recommends against this (because of the danger that runaway code could get to the reprogramming block). Gary Olmstead Toucan Technology Ventura CA At 10:35 AM 6/30/03 -0700, you wrote: >We have been using the CABLE12 interface cable to program a 68HC12 target >for the last year. We use the Cosmic compiler to generate .H12 files which >are then downloaded to the Flash and EEPROM (using Cosmic's ZAP) of the >MC912 processor on our product. > >We would like to be able to develop code (and create a .H12 file) in-house >and send the .H12 file to a customer who could then re-program the micro on >his device with the updated code. > >What are the minimum/cheapest products (P&E Micro or otherwise) the remote >customer would need to re-program his micro? Assume he has a PC with a >parallel port and is not interested in doing any debugging. (I guess this >process could be considered updating the firmware.) Would the BDM MULTILINK >alone be sufficient, or would he also need additional software (e.g., >PROG12Z) to download the code? Do you know if there are any other >light-weight (without debugging features) software and hardware solutions >that would accomplish this? > >Andrew Heninger > |
|
|
Reply by ●June 30, 20032003-06-30
|
At 10:54 AM 6/30/2003 -0700, you wrote: >Also, which device(s) are you supporting? We have a D60A in the field, and >Motorola has recently (for us, anyway, we don't ship a lot of these) >changed the flash security to add a lock bit that is programmed in a shadow >byte in the EEPROM. ... >Unfortunately, the alternative seems to be to write a custom program, and >keep it in the boot block. Motorola specifically recommends against this >(because of the danger that runaway code could get to the reprogramming >block). Sounds interesting. We are putting our loader in the boot block and setting the D60A bits to protect it. A random "erase" function won't wipe it out. However, sufficient runaway code could certainly (in theory, at least) manage to clear the protection and then erase the boot block. Haven't had it happen yet... but then we currently only have prototype quantities of these units in the field. A more elaborate protection scheme would certainly be preferred (which I believe some of the later versions of the HC12 have). jmk ----------- James M. Knox TriSoft ph 512-385-0316 1109-A Shady Lane fax 512-366-4331 Austin, Tx 78721 ----------- |
Reply by ●June 30, 20032003-06-30
|
Who at Motorola "specifically recommends against this (because of the danger that runaway code could get to the reprogramming block)"? Is there an APP note or engineering bulletin? I have operated with a serial download monitor for almost 2 years on a DG128A platform and have had ZERO problems. If you lock the boot block ppage ASAP on startup (this is a write once register), have a good reset generator, clean power, etc. then in my experience, a serial downloader is very reliable. If there is an issue that Motorola has with this technique I would sure like to know! -----Original Message----- From: Gary Olmstead [mailto:] Sent: Monday, June 30, 2003 1:55 PM To: Subject: Re: [68HC12] Minimum equipment to re-program HC12 How sophisticated is your customer? If they have "some" technical knowledge on-board, then any commercial product is probably OK. If not, then the problem is that if you give them complete instructions, and something goes wrong, how are they going to fix it? Also, which device(s) are you supporting? We have a D60A in the field, and Motorola has recently (for us, anyway, we don't ship a lot of these) changed the flash security to add a lock bit that is programmed in a shadow byte in the EEPROM. I forget the details, but the shadow byte is controlled by a byte in RAM, or Flash, or someplace. Sorting through all of this seems to be a 27 step process, with several resets along the way. Our customer is very sophisticated, but I don't know yet if I can hand it off to them or not (especially since I haven't got it working myself, yet.) Unfortunately, the alternative seems to be to write a custom program, and keep it in the boot block. Motorola specifically recommends against this (because of the danger that runaway code could get to the reprogramming block). Gary Olmstead Toucan Technology Ventura CA At 10:35 AM 6/30/03 -0700, you wrote: >We have been using the CABLE12 interface cable to program a 68HC12 target >for the last year. We use the Cosmic compiler to generate .H12 files which >are then downloaded to the Flash and EEPROM (using Cosmic's ZAP) of the >MC912 processor on our product. > >We would like to be able to develop code (and create a .H12 file) in-house >and send the .H12 file to a customer who could then re-program the micro on >his device with the updated code. > >What are the minimum/cheapest products (P&E Micro or otherwise) the remote >customer would need to re-program his micro? Assume he has a PC with a >parallel port and is not interested in doing any debugging. (I guess this >process could be considered updating the firmware.) Would the BDM MULTILINK >alone be sufficient, or would he also need additional software (e.g., >PROG12Z) to download the code? Do you know if there are any other >light-weight (without debugging features) software and hardware solutions >that would accomplish this? > >Andrew Heninger > -------------------- ">http://docs.yahoo.com/info/terms/ This e-mail and any files transmitted with it ( Message ) are confidential and may contain privileged information. This Message is intended solely for the addressee(s). If you have received this Message in error, please inform us promptly by reply e-mail then delete the Message and destroy any printed copy of it. Any unauthorized use, review, retransmission, dissemination, distribution, printing or copying of this Message or any part thereof is strictly prohibited. E-mails are susceptible to alteration. Neither Technip-Coflexip nor any of its subsidiaries and affiliates shall be liable for the Message if altered, changed or falsified |
Reply by ●June 30, 20032003-06-30
|
It is in the book called 68HC912D60 Advance Information, Rev 2.0. Dated July 27, 2000. Motorola part number MC68HC912D60/D. Page 86, fourth paragraph. However, this is for a _very_ different FLASH architecture compared to what you have. I am certain that it also appears in an ap-note, but it is on my "other" computer, which is across town, and I won't be back there this week. A quick search at Motorola failed to turn it up. I have actually seen this happen. It was repeatable enough that I was able to capture the sequence on a logic analyzer. The process was quite interesting, but too long to detail here. The short answer is that it was caused by the fact that we didn't have one of those reset control ICs, and our power supply did some very weird things at shut down. I should also add that this was on an MC146805E2, which treated undefined instructions as NOPs. The memory that it reprogrammed was an external EEPROM. I would say that you are probably OK, and I have my data confused. Wouldn't be the first time. Gary Olmstead Toucan Technology Ventura CA At 08:19 PM 6/30/03 +0200, you wrote: > >Who at Motorola "specifically recommends against this (because of the danger >that runaway code could get to the reprogramming block)"? Is there an APP >note or engineering bulletin? I have operated with a serial download >monitor for almost 2 years on a DG128A platform and have had ZERO problems. >If you lock the boot block ppage ASAP on startup (this is a write once >register), have a good reset generator, clean power, etc. then in my >experience, a serial downloader is very reliable. > >If there is an issue that Motorola has with this technique I would sure like >to know! > |
Reply by ●July 1, 20032003-07-01
|
Thanks for clarifying that... -----Original Message----- From: Gary Olmstead [mailto:] Sent: Monday, June 30, 2003 7:58 PM To: Subject: RE: [68HC12] Minimum equipment to re-program HC12 It is in the book called 68HC912D60 Advance Information, Rev 2.0. Dated July 27, 2000. Motorola part number MC68HC912D60/D. Page 86, fourth paragraph. However, this is for a _very_ different FLASH architecture compared to what you have. I am certain that it also appears in an ap-note, but it is on my "other" computer, which is across town, and I won't be back there this week. A quick search at Motorola failed to turn it up. I have actually seen this happen. It was repeatable enough that I was able to capture the sequence on a logic analyzer. The process was quite interesting, but too long to detail here. The short answer is that it was caused by the fact that we didn't have one of those reset control ICs, and our power supply did some very weird things at shut down. I should also add that this was on an MC146805E2, which treated undefined instructions as NOPs. The memory that it reprogrammed was an external EEPROM. I would say that you are probably OK, and I have my data confused. Wouldn't be the first time. Gary Olmstead Toucan Technology Ventura CA At 08:19 PM 6/30/03 +0200, you wrote: > >Who at Motorola "specifically recommends against this (because of the danger >that runaway code could get to the reprogramming block)"? Is there an APP >note or engineering bulletin? I have operated with a serial download >monitor for almost 2 years on a DG128A platform and have had ZERO problems. >If you lock the boot block ppage ASAP on startup (this is a write once >register), have a good reset generator, clean power, etc. then in my >experience, a serial downloader is very reliable. > >If there is an issue that Motorola has with this technique I would sure like >to know! > -------------------- ">http://docs.yahoo.com/info/terms/ This e-mail and any files transmitted with it ( Message ) are confidential and may contain privileged information. This Message is intended solely for the addressee(s). If you have received this Message in error, please inform us promptly by reply e-mail then delete the Message and destroy any printed copy of it. Any unauthorized use, review, retransmission, dissemination, distribution, printing or copying of this Message or any part thereof is strictly prohibited. E-mails are susceptible to alteration. Neither Technip-Coflexip nor any of its subsidiaries and affiliates shall be liable for the Message if altered, changed or falsified |
