|
Hi folks Has anyone here ever successfully programmed flash in a 9s12 device from a bootloader when the chip is secured? The chip I am using is the 9S12DG128 3l40K mask set which has the common EEPROM/FLASH programming error fixed. I am still having some troubles and was hoping someone could offer some insight. The problem I face is that flash block 0 can not be programmed from code resident in flash block 0. To perform this programming the routines are copied to RAM and run from there. This works fine in non secure mode. However, in secure mode I see that the ACCERR bit is set if any command other than Mass erase originates from a non secure memory which I guess includes RAM since the flash can no longer be programmed. At first I thought I would copy the programming routines to flash block 1. This does not work becasue all of block 1 is paged which means to write to the flash block 0 I have to change the PPAGE register, at which point my program locks up. Can these routines be copied to EEPROM and run from there? Does anyone have any such experience with this problem? Thanks in advance |
|
|
Flash programming from a bootloader
Started by ●December 8, 2004
Reply by ●December 9, 20042004-12-09
|
My understanding of the security was that it prevented anyone from using the
BDM to read or otherwise tamper with (aside from mass erase) the flash and
eeprom. I would think then that internal writing....from flash to flash would still be possible. This would allow a bootloader program to install a new piece of software without removing the security of the BDM. If you can not write from internal memory to other areas of memory the point of a bootloader is useless since it requires the removal of any security thereby easily allowing someone to read the software. -Dave ----- Original Message ----- From: Jefferson Smith To: Sent: Thursday, December 09, 2004 11:55 AM Subject: [68HC12] Re: Flash programming from a bootloader Let me get this straight... You want to program some of the flash after you have set the security mode? The purpose of security is to protect the flash from any operation except bulk erase. It is to protect you from anyone reading or tampering with your code after you shipped your product. The only reason you can bulk-erase a secured chip is so the hardware will be reusable, but make sure the software is not. So, what are you saying is wrong? --jeffs --- In , "dwild.geo" <david.wild@a...> wrote: > > Hi folks > > Has anyone here ever successfully programmed flash in a 9s12 device > from a bootloader when the chip is secured? The chip I am using is > the 9S12DG128 3l40K mask set which has the common EEPROM/FLASH > programming error fixed. I am still having some troubles and was > hoping someone could offer some insight. > > The problem I face is that flash block 0 can not be programmed from > code resident in flash block 0. To perform this programming the > routines are copied to RAM and run from there. This works fine in > non secure mode. However, in secure mode I see that the ACCERR bit > is set if any command other than Mass erase originates from a non > secure memory which I guess includes RAM since the flash can no > longer be programmed. > > At first I thought I would copy the programming routines to flash > block 1. This does not work becasue all of block 1 is paged which > means to write to the flash block 0 I have to change the PPAGE > register, at which point my program locks up. Can these routines be > copied to EEPROM and run from there? Does anyone have any such > experience with this problem? > > Thanks in advance ------ Yahoo! Groups Links a.. To |
|
|
Reply by ●December 9, 20042004-12-09
|
I agree, it wouldn't be convenient that you can't store in flash for something like config data, but it's probably a security issue. I have not verified that you really are not allowed to write to eeprom (or flash sectors). The worry is that someone else could program a portion with their own code, get that code to execute, and then simple output your entire program through some port, thus compromising the security. So it would plain not be safe to allow. --jeffs --- In , "David Wild" <david.wild@a...> wrote: > My understanding of the security was that it prevented anyone from using the BDM to read or otherwise tamper with (aside from mass erase) the flash and eeprom. > I would think then that internal writing....from flash to flash would still be possible. This would allow a bootloader program to install a new piece of software without removing the security of the BDM. > > If you can not write from internal memory to other areas of memory the point of a bootloader is useless since it requires the removal of any security thereby easily allowing someone to read the software. > > > -Dave |
Reply by ●December 9, 20042004-12-09
|
I understand the security concern with a bootloader and that is why I think
the onus is on the sw developer to have some encryption scheme for any code that
is to be uploaded. I guess that since Freescale has identified an errata stating that the FLASH & EEPROM cannot be written to when the chip is secured and in single chip mode then it must be possible to do such a thing in later masksets where this was not indentified as an errata.(http://www.freescale.com/files/microcontrollers/doc/errata/MSE9S12DT128B_1L85D.pdf) With one of the later mask sets I certainly can write to EEPROM in secure mode so I can't help but think I must be able to do the same to flash. I am just not going about it the right way. I have tried running the flash programming routines to EEPROM but for some reason that software only works if I am using a BDM debugger and stepping through the code. In free run mode it wont even JSR to the correct location in EEPROM. grrr.... lol Any comments form anyone? -Dave ----- Original Message ----- From: Jefferson Smith To: Sent: Thursday, December 09, 2004 12:41 PM Subject: SPAM-LOW: [68HC12] Re: Flash programming from a bootloader I agree, it wouldn't be convenient that you can't store in flash for something like config data, but it's probably a security issue. I have not verified that you really are not allowed to write to eeprom (or flash sectors). The worry is that someone else could program a portion with their own code, get that code to execute, and then simple output your entire program through some port, thus compromising the security. So it would plain not be safe to allow. --jeffs --- In , "David Wild" <david.wild@a...> wrote: > My understanding of the security was that it prevented anyone from using the BDM to read or otherwise tamper with (aside from mass erase) the flash and eeprom. > I would think then that internal writing....from flash to flash would still be possible. This would allow a bootloader program to install a new piece of software without removing the security of the BDM. > > If you can not write from internal memory to other areas of memory the point of a bootloader is useless since it requires the removal of any security thereby easily allowing someone to read the software. > > > -Dave Yahoo! Groups Sponsor Get unlimited calls to U.S./Canada ------ Yahoo! Groups Links a.. To |
|
|
Reply by ●December 9, 20042004-12-09
|
--- In , "David Wild" <david.wild@a...> wrote: Hi David, > I understand the security concern with a bootloader and that is why I think the onus is on the sw developer to have some encryption scheme for any code that is to be uploaded. Very true, there is a warning somewhere about internal monitors and loaders, i.e. make sure you don't defeat the security. The BDM does things its own way and switches modes to suit itself, that is fine but it results in different behaviour when it is active. To get around this I retrieved some old monitor software out of the dark ages and used that to complement the BDM hardware with the software, works well. I allows trace (in Ram only of course)while the unit is secured by using the serial link that stops interference from the BDM after locking or in different operating modes. I think there is some Freescale stuff around for the downloading, if you want something more elaborate but mine would be probably easier to understand, the serial and monitor stuff is in the file area if you want to have a play. As you said, no problems programming EE, makes me think also that flash can be done, haven't tried it though. Regards, Theo |
Reply by ●December 9, 20042004-12-09
|
I wrote a CAN based bootloader that runs at power up and checks a CRC and
runs the user code if valid. The user can force the program to stop and return to the bootloader and await encoded CAN messages to download a new program to flash. The entire process is done in secure mode and uses a RAM routine to write to the flash. The whole process relies on the fact that the HC12 must have my bootloader programmed in initially and because the S12 file is encoded and past through the download program on the PC untouched, I can email my customers firmware updates without worry of it being loaded on a board not build by me. So, to answer the initial question, yes you can flash memory internally in secure mode. All of the products on www.brightan.com have this feature. I have considered selling a kit that would include a CAN-4-USB interface, PC download software (C DLL source + VB app source code) as well the HC12 source code (ICC12 C) for the bootloader. I would not include the encoding portion of the system for obvious reasons but there is no reason a person could not come up with their own encoding scheme. If there is any interest, please let me know and I am also open to suggestions as to what a fair price would be. The original poster can also email me directly for help if they like. Steve Steven D. Letkeman BSc. President - Zanthic Technologies Inc. 403-526-8318 www.zanthic.com Embedded micro-controllers and CAN interfaces www.brightan.com Automated lighting systems ----- Original Message ----- From: David Wild To: Sent: Thursday, December 09, 2004 11:59 AM Subject: Re: SPAM-LOW: [68HC12] Re: Flash programming from a bootloader I understand the security concern with a bootloader and that is why I think the onus is on the sw developer to have some encryption scheme for any code that is to be uploaded. I guess that since Freescale has identified an errata stating that the FLASH & EEPROM cannot be written to when the chip is secured and in single chip mode then it must be possible to do such a thing in later masksets where this was not indentified as an errata.(http://www.freescale.com/files/microcontrollers/doc/errata/MSE9S12DT128B_1L85D.pdf) With one of the later mask sets I certainly can write to EEPROM in secure mode so I can't help but think I must be able to do the same to flash. I am just not going about it the right way. I have tried running the flash programming routines to EEPROM but for some reason that software only works if I am using a BDM debugger and stepping through the code. In free run mode it wont even JSR to the correct location in EEPROM. grrr.... lol Any comments form anyone? -Dave ----- Original Message ----- From: Jefferson Smith To: Sent: Thursday, December 09, 2004 12:41 PM Subject: SPAM-LOW: [68HC12] Re: Flash programming from a bootloader I agree, it wouldn't be convenient that you can't store in flash for something like config data, but it's probably a security issue. I have not verified that you really are not allowed to write to eeprom (or flash sectors). The worry is that someone else could program a portion with their own code, get that code to execute, and then simple output your entire program through some port, thus compromising the security. So it would plain not be safe to allow. --jeffs --- In , "David Wild" <david.wild@a...> wrote: > My understanding of the security was that it prevented anyone from using the BDM to read or otherwise tamper with (aside from mass erase) the flash and eeprom. > I would think then that internal writing....from flash to flash would still be possible. This would allow a bootloader program to install a new piece of software without removing the security of the BDM. > > If you can not write from internal memory to other areas of memory the point of a bootloader is useless since it requires the removal of any security thereby easily allowing someone to read the software. > > > -Dave Yahoo! Groups Sponsor Get unlimited calls to U.S./Canada ------ Yahoo! Groups Links a.. To Yahoo! Groups Sponsor Get unlimited calls to U.S./Canada ------ Yahoo! Groups Links a.. To |
Reply by ●December 9, 20042004-12-09
|
Looks like the errata says just use the back door key to turn off security, which would allow you to program the flash. Then, maybe a reset enables security again if you didn't erase flash bits which enabled security. --jeffs --- In , "David Wild" <david.wild@a...> wrote: > I understand the security concern with a bootloader and that is why I think the onus is on the sw developer to have some encryption scheme for any code that is to be uploaded. > > I guess that since Freescale has identified an errata stating that the FLASH & EEPROM cannot be written to when the chip is secured and in single chip mode then it must be possible to do such a thing in later masksets where this was not indentified as an errata.(http://www.freescale.com/files/microcontrollers/doc/errata/MSE9S12DT128B_1L85D.pdf) > > With one of the later mask sets I certainly can write to EEPROM in secure mode so I can't help but think I must be able to do the same to flash. I am just not going about it the right way. I have tried running the flash programming routines to EEPROM but for some reason that software only works if I am using a BDM debugger and stepping through the code. In free run mode it wont even JSR to the correct location in EEPROM. > > > grrr.... lol > > Any comments form anyone? > > -Dave > ----- Original Message ----- > From: Jefferson Smith > To: > Sent: Thursday, December 09, 2004 12:41 PM > Subject: SPAM-LOW: [68HC12] Re: Flash programming from a bootloader > > I agree, it wouldn't be convenient that you can't store in flash for > something like config data, but it's probably a security issue. I have > not verified that you really are not allowed to write to eeprom (or > flash sectors). The worry is that someone else could program a > portion with their own code, get that code to execute, and then simple > output your entire program through some port, thus compromising the > security. So it would plain not be safe to allow. --jeffs > --- In , "David Wild" <david.wild@a...> wrote: > > My understanding of the security was that it prevented anyone from > using the BDM to read or otherwise tamper with (aside from mass erase) > the flash and eeprom. > > I would think then that internal writing....from flash to flash > would still be possible. This would allow a bootloader program to > install a new piece of software without removing the security of the BDM. > > > > If you can not write from internal memory to other areas of memory > the point of a bootloader is useless since it requires the removal of > any security thereby easily allowing someone to read the software. > > > > > > -Dave > Yahoo! Groups Sponsor > > Get unlimited calls to > > U.S./Canada ------ > Yahoo! Groups Links > > a.. To > > |
Reply by ●December 9, 20042004-12-09
|
yes I saw that too Jeff. But since removing security through the backdoor
allows the code to be read from the chip, albeit temporarily, it is not a good
option. I still believe that somehow the already installed bootloader should be able to take data over the serial port and rewrite the flash, even while the chip is secured. I thought a lot of people would have done this already but maybe I am the odd one out, as often is the case :) ----- Original Message ----- From: Jefferson Smith To: Sent: Thursday, December 09, 2004 3:24 PM Subject: SPAM-LOW: [68HC12] Re: Flash programming from a bootloader Looks like the errata says just use the back door key to turn off security, which would allow you to program the flash. Then, maybe a reset enables security again if you didn't erase flash bits which enabled security. --jeffs --- In , "David Wild" <david.wild@a...> wrote: > I understand the security concern with a bootloader and that is why I think the onus is on the sw developer to have some encryption scheme for any code that is to be uploaded. > > I guess that since Freescale has identified an errata stating that the FLASH & EEPROM cannot be written to when the chip is secured and in single chip mode then it must be possible to do such a thing in later masksets where this was not indentified as an errata.(http://www.freescale.com/files/microcontrollers/doc/errata/MSE9S12DT128B_1L85D.pdf) > > With one of the later mask sets I certainly can write to EEPROM in secure mode so I can't help but think I must be able to do the same to flash. I am just not going about it the right way. I have tried running the flash programming routines to EEPROM but for some reason that software only works if I am using a BDM debugger and stepping through the code. In free run mode it wont even JSR to the correct location in EEPROM. > > > grrr.... lol > > Any comments form anyone? > > -Dave > ----- Original Message ----- > From: Jefferson Smith > To: > Sent: Thursday, December 09, 2004 12:41 PM > Subject: SPAM-LOW: [68HC12] Re: Flash programming from a bootloader > > I agree, it wouldn't be convenient that you can't store in flash for > something like config data, but it's probably a security issue. I have > not verified that you really are not allowed to write to eeprom (or > flash sectors). The worry is that someone else could program a > portion with their own code, get that code to execute, and then simple > output your entire program through some port, thus compromising the > security. So it would plain not be safe to allow. --jeffs > --- In , "David Wild" <david.wild@a...> wrote: > > My understanding of the security was that it prevented anyone from > using the BDM to read or otherwise tamper with (aside from mass erase) > the flash and eeprom. > > I would think then that internal writing....from flash to flash > would still be possible. This would allow a bootloader program to > install a new piece of software without removing the security of the BDM. > > > > If you can not write from internal memory to other areas of memory > the point of a bootloader is useless since it requires the removal of > any security thereby easily allowing someone to read the software. > > > > > > -Dave ------ Yahoo! Groups Links a.. To |
|
|
Reply by ●December 9, 20042004-12-09
|
Hey Steve Am I to understand that you had no trouble writing to a secure flash from routines held in RAM? That is what I was trying to do but it always locked up. Then I read that the ACCERR bit will get set if you try to write to flash from non secure memory (like RAM for example?) I would be interested in any comments you had about the flash writing process and how you went about it. Which chip were you using? -Dave ----- Original Message ----- From: Steve Letkeman To: Sent: Thursday, December 09, 2004 3:16 PM Subject: Re: [68HC12] Re: Flash programming from a bootloader I wrote a CAN based bootloader that runs at power up and checks a CRC and runs the user code if valid. The user can force the program to stop and return to the bootloader and await encoded CAN messages to download a new program to flash. The entire process is done in secure mode and uses a RAM routine to write to the flash. The whole process relies on the fact that the HC12 must have my bootloader programmed in initially and because the S12 file is encoded and past through the download program on the PC untouched, I can email my customers firmware updates without worry of it being loaded on a board not build by me. So, to answer the initial question, yes you can flash memory internally in secure mode. All of the products on www.brightan.com have this feature. I have considered selling a kit that would include a CAN-4-USB interface, PC download software (C DLL source + VB app source code) as well the HC12 source code (ICC12 C) for the bootloader. I would not include the encoding portion of the system for obvious reasons but there is no reason a person could not come up with their own encoding scheme. If there is any interest, please let me know and I am also open to suggestions as to what a fair price would be. The original poster can also email me directly for help if they like. Steve Steven D. Letkeman BSc. President - Zanthic Technologies Inc. 403-526-8318 www.zanthic.com Embedded micro-controllers and CAN interfaces www.brightan.com Automated lighting systems ----- Original Message ----- From: David Wild To: Sent: Thursday, December 09, 2004 11:59 AM Subject: Re: SPAM-LOW: [68HC12] Re: Flash programming from a bootloader I understand the security concern with a bootloader and that is why I think the onus is on the sw developer to have some encryption scheme for any code that is to be uploaded. I guess that since Freescale has identified an errata stating that the FLASH & EEPROM cannot be written to when the chip is secured and in single chip mode then it must be possible to do such a thing in later masksets where this was not indentified as an errata.(http://www.freescale.com/files/microcontrollers/doc/errata/MSE9S12DT128B_1L85D.pdf) With one of the later mask sets I certainly can write to EEPROM in secure mode so I can't help but think I must be able to do the same to flash. I am just not going about it the right way. I have tried running the flash programming routines to EEPROM but for some reason that software only works if I am using a BDM debugger and stepping through the code. In free run mode it wont even JSR to the correct location in EEPROM. grrr.... lol Any comments form anyone? -Dave ----- Original Message ----- From: Jefferson Smith To: Sent: Thursday, December 09, 2004 12:41 PM Subject: SPAM-LOW: [68HC12] Re: Flash programming from a bootloader I agree, it wouldn't be convenient that you can't store in flash for something like config data, but it's probably a security issue. I have not verified that you really are not allowed to write to eeprom (or flash sectors). The worry is that someone else could program a portion with their own code, get that code to execute, and then simple output your entire program through some port, thus compromising the security. So it would plain not be safe to allow. --jeffs --- In , "David Wild" <david.wild@a...> wrote: > My understanding of the security was that it prevented anyone from using the BDM to read or otherwise tamper with (aside from mass erase) the flash and eeprom. > I would think then that internal writing....from flash to flash would still be possible. This would allow a bootloader program to install a new piece of software without removing the security of the BDM. > > If you can not write from internal memory to other areas of memory the point of a bootloader is useless since it requires the removal of any security thereby easily allowing someone to read the software. > > > -Dave Yahoo! Groups Sponsor Get unlimited calls to U.S./Canada ------ Yahoo! Groups Links a.. To Yahoo! Groups Sponsor Get unlimited calls to U.S./Canada ------ Yahoo! Groups Links a.. To Yahoo! Groups Sponsor Get unlimited calls to U.S./Canada ------ Yahoo! Groups Links a.. To |
Reply by ●December 9, 20042004-12-09
|
I agree it would be more practical than momentarily disabling sec. The reason I haven't done much with security is because being the only programmer for a small company, I was happy to just know that I could secure the chip and erase it when I needed new softare. Here is an idea I got from the CAN bootloader message: 1. push relocatable bootloader on stack 2. execute bootloader in ram 3. mass-erase flash 4. disable security (because flash is blank) 5. load upgrade 6. enable security But I suppose you have mentioned it's not safe having a moment with the program loaded and no security. Can someone intercept this with BDM during that time or something? --jeffs --- In , "David Wild" <david.wild@a...> wrote: > I thought a lot of people would have done this already but maybe I am the odd one out, as often is the case :) |
