Sign in
Search 68hc12
Subscribe to 68hc12
68hc12 by Keywords
68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC
Ads
Discussion Groups
Discussion Groups | 68HC12 | Unsecuring the flash
Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
Unsecuring the flash - bdesyf - Apr 30 16:21:00 2003
|
Hello, I am trying to unsecure the flash, as I want to update the code in my system, based on a HCS12DP256. I read the document concerning the flash and the application note. I still can't answer a question: how do I know what is the value of the backdoor key, to unsecure the flash? Do I have to declare a table (in my code) at the address 0xFF00 with the values I want, or it is hardware specific? Or else? Thanks for your time. Frederic. |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Unsecuring the flash - Steve Russell - Apr 30 22:18:00 2003
|
Hi Frederic The backdoor key is NOT required for the normal development type of operations. You can always un-secure a HCS-12 MCU by completely erasing flash and EEPROM without using the backdoor key. If the MCU is not "secured", the backdoor key is not required. I haven't used the backdoor key at all, so I haven't tested my understanding. I don't believe that I can do better at explaining it than quote from AN2400?D Rev 2. ==================== AN2400?D Rev 2 p. 44 says: ================= Backdoor Key Access ------------------- In Normal modes (Single Chip and Expanded), security can be temporarily disabled by means of the Backdoor Key access method. This method requires that: The Backdoor Key at $FF00 to $FF07 has been programmed to a valid value. The KEYEN[1:0] bits within the Flash Options/Security byte select enabled. In Single Chip mode, the application program programmed into the microcontroller must be designed to have the capability to write to the Backdoor Key locations. The Backdoor Key values themselves would not normally be stored within the application data, and so the application program would have to be designed to receive the Backdoor Key values from an external source, through a serial port for example. It is not possible to download the backdoor keys using Background Debug Mode. The Backdoor Key Access method is useful because it allows debugging of a secured microcontroller, without having to erase the Flash. This is particularly useful for failure analysis. NOTE: No word of the Backdoor Key is allowed to have the value $0000 or $FFFF. Backdoor Key Access Sequence: 1. Set the KEYACC bit in the Flash Configuration register FCNFG. 2. Write the first 16-bit word of the backdoor key to $FF00. 3. Write the second 16-bit word of the backdoor key to $FF02. 4. Write the third 16-bit word of the backdoor key to $FF04. 5. Write the fourth 16-bit word of the backdoor key to $FF06. 6. Clear the KEYACC bit in the Flash Configuration register FCNFG. NOTE: Flash cannot be read while KEYACC is set. Therefore the code for the Backdoor Key access sequence must execute from RAM. If all four 16-bit words match the Flash contents at $FF00 to $FF07, the microcontroller will be unsecured and the security bits SEC[1:0] in the Flash Security register FSEC will be forced to the unsecured state, 10. The contents of the Flash Options/Security byte are not changed by this procedure, and so the microcontroller will revert to the secure state after the next reset, unless further action is taken as detailed below. If any of the four 16-bit words do not match the Flash contents at $FF00 to $FF07, the microcontroller will remain secured. Reprogramming the Security Bits ------------------------------- In Normal Single Chip Mode, security can also be disabled by means of erasing and reprogramming the security bits within Flash Options/Security byte to the unsecured value. As the erase operation will erase the entire sector from $FE00 to $FFFF, the Backdoor Key and the interrupt vectors will also be erased and so this method is not recommended for Normal Single Chip mode. The application software can only erase and program the Flash Options/Security byte if the Flash sector containing the Flash Options/Security byte is not protected (see Flash Protection). Thus Flash protection is a useful means of preventing this method. The microcontroller will enter the unsecured state after the next reset following the programming of the security bits to the unsecured value. This method requires: That the application software previously programmed into the microcontroller has been designed to have the capability to erase and program the Flash Options/Security byte, or That security is first disabled using the Backdoor Key method, allowing BDM to be used to issue commands to erase and program the Flash Options/Security byte, and The Flash sector containing the Flash Options/Security byte is not protected. ================== End of Quote from AN2400 Rev 2 ============ My understanding is that if you have a secured application in the field, you could talk to it via SPI or CAN and give it a magic number (not necessarily the actual backdoor key programmed into the flash) The application code would verify that your magic number indicates that you are authorized, and would then copy the backdoor key code described in AN2400 into RAM and execute it. At this point you could connect a BDM emulator to your MCU and use it for debugging. (You application would have to do the backdoor key negotiation via SPI or CAN after every reset to re-enable the BDM access.) My guess is that for almost any field debugging situation, having a data dump application that outputs debugging data over SPI or CAM would be much quicker to debug that the backdoor key procedure I just described. I have put some more notes in your message below. Steve At 02:21 PM 4/30/2003, you wrote: >Hello, > >I am trying to unsecure the flash, as I want to update the code in my >system, based on a HCS12DP256. Normal development programming just leaves the flash as "un-secure" and no backdoor key is required for flash programming or debugging. You can do field upgrading without using the backdoor key by un-securing the MCU by completely erasing flash and EEPROM. This would lose any calibration data you have in EEPROM, so it would be necessary to have the application dump the calibration data before the upgrade. >I read the document concerning the flash and the application note. > >I still can't answer a question: how do I know what is the value of >the backdoor key, to unsecure the flash? One copy of the backdoor key is programmed by you into flash as described in AN2400. A part of your running application code is required to be in RAM when it is executed. This code writes another copy of the backdoor key into the backdoor key locations in the registers as described in AN2400. If the two copies match, the MCU is un-secure until the next reset. >Do I have to declare a table >(in my code) at the address 0xFF00 with the values I want, or it is >hardware specific? Or else? One copy of the backdoor key should be at 0xFF00. A table at that location in your flash programming file would do that. >Thanks for your time. > >Frederic. >************************************************************************* Steve Russell mailto: Senior Software Design Engineer http://www.nohau.com Nohau Corporation phone: (408)866-1820 51 East Campbell Avenue fax: (408)378-7869 Campbell, CA 95008 ************************************************************************* |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Unsecuring the flash - Steve Russell - May 2 13:06:00 2003
|
Hi Frederic The backdoor key is NOT required for the normal development type of operations. You can always un-secure a HCS-12 MCU by completely erasing flash and EEPROM without using the backdoor key. If the MCU is not "secured", the backdoor key is not required. I haven't used the backdoor key at all, so I haven't tested my understanding. I don't believe that I can do better at explaining it than quote from AN2400?D Rev 2. ==================== AN2400?D Rev 2 p. 44 says: ================= Backdoor Key Access ------------------- In Normal modes (Single Chip and Expanded), security can be temporarily disabled by means of the Backdoor Key access method. This method requires that: The Backdoor Key at $FF00 to $FF07 has been programmed to a valid value. The KEYEN[1:0] bits within the Flash Options/Security byte select enabled. In Single Chip mode, the application program programmed into the microcontroller must be designed to have the capability to write to the Backdoor Key locations. The Backdoor Key values themselves would not normally be stored within the application data, and so the application program would have to be designed to receive the Backdoor Key values from an external source, through a serial port for example. It is not possible to download the backdoor keys using Background Debug Mode. The Backdoor Key Access method is useful because it allows debugging of a secured microcontroller, without having to erase the Flash. This is particularly useful for failure analysis. NOTE: No word of the Backdoor Key is allowed to have the value $0000 or $FFFF. Backdoor Key Access Sequence: 1. Set the KEYACC bit in the Flash Configuration register FCNFG. 2. Write the first 16-bit word of the backdoor key to $FF00. 3. Write the second 16-bit word of the backdoor key to $FF02. 4. Write the third 16-bit word of the backdoor key to $FF04. 5. Write the fourth 16-bit word of the backdoor key to $FF06. 6. Clear the KEYACC bit in the Flash Configuration register FCNFG. NOTE: Flash cannot be read while KEYACC is set. Therefore the code for the Backdoor Key access sequence must execute from RAM. If all four 16-bit words match the Flash contents at $FF00 to $FF07, the microcontroller will be unsecured and the security bits SEC[1:0] in the Flash Security register FSEC will be forced to the unsecured state, 10. The contents of the Flash Options/Security byte are not changed by this procedure, and so the microcontroller will revert to the secure state after the next reset, unless further action is taken as detailed below. If any of the four 16-bit words do not match the Flash contents at $FF00 to $FF07, the microcontroller will remain secured. Reprogramming the Security Bits ------------------------------- In Normal Single Chip Mode, security can also be disabled by means of erasing and reprogramming the security bits within Flash Options/Security byte to the unsecured value. As the erase operation will erase the entire sector from $FE00 to $FFFF, the Backdoor Key and the interrupt vectors will also be erased and so this method is not recommended for Normal Single Chip mode. The application software can only erase and program the Flash Options/Security byte if the Flash sector containing the Flash Options/Security byte is not protected (see Flash Protection). Thus Flash protection is a useful means of preventing this method. The microcontroller will enter the unsecured state after the next reset following the programming of the security bits to the unsecured value. This method requires: That the application software previously programmed into the microcontroller has been designed to have the capability to erase and program the Flash Options/Security byte, or That security is first disabled using the Backdoor Key method, allowing BDM to be used to issue commands to erase and program the Flash Options/Security byte, and The Flash sector containing the Flash Options/Security byte is not protected. ================== End of Quote from AN2400 Rev 2 ============ My understanding is that if you have a secured application in the field, you could talk to it via SPI or CAN and give it a magic number (not necessarily the actual backdoor key programmed into the flash) The application code would verify that your magic number indicates that you are authorized, and would then copy the backdoor key code described in AN2400 into RAM and execute it. At this point you could connect a BDM emulator to your MCU and use it for debugging. (You application would have to do the backdoor key negotiation via SPI or CAN after every reset to re-enable the BDM access.) My guess is that for almost any field debugging situation, having a data dump application that outputs debugging data over SPI or CAM would be much quicker to debug that the backdoor key procedure I just described. I have put some more notes in your message below. Steve At 02:21 PM 4/30/2003, you wrote: >Hello, > >I am trying to unsecure the flash, as I want to update the code in my >system, based on a HCS12DP256. Normal development programming just leaves the flash as "un-secure" and no backdoor key is required for flash programming or debugging. You can do field upgrading without using the backdoor key by un-securing the MCU by completely erasing flash and EEPROM. This would lose any calibration data you have in EEPROM, so it would be necessary to have the application dump the calibration data before the upgrade. >I read the document concerning the flash and the application note. > >I still can't answer a question: how do I know what is the value of >the backdoor key, to unsecure the flash? One copy of the backdoor key is programmed by you into flash as described in AN2400. A part of your running application code is required to be in RAM when it is executed. This code writes another copy of the backdoor key into the backdoor key locations in the registers as described in AN2400. If the two copies match, the MCU is un-secure until the next reset. >Do I have to declare a table >(in my code) at the address 0xFF00 with the values I want, or it is >hardware specific? Or else? One copy of the backdoor key should be at 0xFF00. A table at that location in your flash programming file would do that. >Thanks for your time. > >Frederic. >************************************************************************* Steve Russell mailto: Senior Software Design Engineer http://www.nohau.com Nohau Corporation phone: (408)866-1820 51 East Campbell Avenue fax: (408)378-7869 Campbell, CA 95008 ************************************************************************* |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Unsecuring the flash - Steve Russell - May 2 13:09:00 2003
|
Hi Frederic The backdoor key is NOT required for the normal development type of operations. You can always un-secure a HCS-12 MCU by completely erasing flash and EEPROM without using the backdoor key. If the MCU is not "secured", the backdoor key is not required. I haven't used the backdoor key at all, so I haven't tested my understanding. I don't believe that I can do better at explaining it than quote from AN2400?D Rev 2. ==================== AN2400?D Rev 2 p. 44 says: ================= Backdoor Key Access ------------------- In Normal modes (Single Chip and Expanded), security can be temporarily disabled by means of the Backdoor Key access method. This method requires that: The Backdoor Key at $FF00 to $FF07 has been programmed to a valid value. The KEYEN[1:0] bits within the Flash Options/Security byte select 'enabled'. In Single Chip mode, the application program programmed into the microcontroller must be designed to have the capability to write to the Backdoor Key locations. The Backdoor Key values themselves would not normally be stored within the application data, and so the application program would have to be designed to receive the Backdoor Key values from an external source, through a serial port for example. It is not possible to download the backdoor keys using Background Debug Mode. The Backdoor Key Access method is useful because it allows debugging of a secured microcontroller, without having to erase the Flash. This is particularly useful for failure analysis. NOTE: No word of the Backdoor Key is allowed to have the value $0000 or $FFFF. Backdoor Key Access Sequence: 1. Set the KEYACC bit in the Flash Configuration register FCNFG. 2. Write the first 16-bit word of the backdoor key to $FF00. 3. Write the second 16-bit word of the backdoor key to $FF02. 4. Write the third 16-bit word of the backdoor key to $FF04. 5. Write the fourth 16-bit word of the backdoor key to $FF06. 6. Clear the KEYACC bit in the Flash Configuration register FCNFG. NOTE: Flash cannot be read while KEYACC is set. Therefore the code for the Backdoor Key access sequence must execute from RAM. If all four 16-bit words match the Flash contents at $FF00 to $FF07, the microcontroller will be unsecured and the security bits SEC[1:0] in the Flash Security register FSEC will be forced to the unsecured state, '10'. The contents of the Flash Options/Security byte are not changed by this procedure, and so the microcontroller will revert to the secure state after the next reset, unless further action is taken as detailed below. If any of the four 16-bit words do not match the Flash contents at $FF00 to $FF07, the microcontroller will remain secured. Reprogramming the Security Bits ------------------------------- In Normal Single Chip Mode, security can also be disabled by means of erasing and reprogramming the security bits within Flash Options/Security byte to the unsecured value. As the erase operation will erase the entire sector from $FE00 to $FFFF, the Backdoor Key and the interrupt vectors will also be erased and so this method is not recommended for Normal Single Chip mode. The application software can only erase and program the Flash Options/Security byte if the Flash sector containing the Flash Options/Security byte is not protected (see Flash Protection). Thus Flash protection is a useful means of preventing this method. The microcontroller will enter the unsecured state after the next reset following the programming of the security bits to the unsecured value. This method requires: That the application software previously programmed into the microcontroller has been designed to have the capability to erase and program the Flash Options/Security byte, or That security is first disabled using the Backdoor Key method, allowing BDM to be used to issue commands to erase and program the Flash Options/Security byte, and The Flash sector containing the Flash Options/Security byte is not protected. ================== End of Quote from AN2400 Rev 2 ============ My understanding is that if you have a secured application in the field, you could talk to it via SPI or CAN and give it a magic number (not necessarily the actual backdoor key programmed into the flash) The application code would verify that your magic number indicates that you are authorized, and would then copy the backdoor key code described in AN2400 into RAM and execute it. At this point you could connect a BDM emulator to your MCU and use it for debugging. (You application would have to do the backdoor key negotiation via SPI or CAN after every reset to re-enable the BDM access.) My guess is that for almost any field debugging situation, having a data dump application that outputs debugging data over SPI or CAM would be much quicker to debug that the backdoor key procedure I just described. I have put some more notes in your message below. Steve At 02:21 PM 4/30/2003, you wrote: > Hello, > > I am trying to unsecure the flash, as I want to update the code in my > system, based on a HCS12DP256. Normal development programming just leaves the flash as "un-secure" and no backdoor key is required for flash programming or debugging. You can do field upgrading without using the backdoor key by un-securing the MCU by completely erasing flash and EEPROM. This would lose any calibration data you have in EEPROM, so it would be necessary to have the application dump the calibration data before the upgrade. > I read the document concerning the flash and the application note. > > I still can't answer a question: how do I know what is the value of > the backdoor key, to unsecure the flash? One copy of the backdoor key is programmed by you into flash as described in AN2400. A part of your running application code is required to be in RAM when it is executed. This code writes another copy of the backdoor key into the backdoor key locations in the registers as described in AN2400. If the two copies match, the MCU is un-secure until the next reset. > Do I have to declare a table > (in my code) at the address 0xFF00 with the values I want, or it is > hardware specific? Or else? One copy of the backdoor key should be at 0xFF00. A table at that location in your flash programming file would do that. > Thanks for your time. > > Frederic. ************************************************************************* Steve Russell mailto: Senior Software Design Engineer http://www.nohau.com Nohau Corporation phone: (408)866-1820 51 East Campbell Avenue fax: (408)378-7869 Campbell, CA 95008 ************************************************************************* |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )