Yes they can use the bdm tools to get access to the chip during that brief
moment of unsecured access. That was verified from a Freescale FAE. Very
dissapointing but thats how it goes. So I am still pretty hesitant to do any unsecuring at all. Steve seems to have gotten his flash to program from RAM so I assume I was just doing something wrong. Hopefully he posts something back soon lol. ----- Original Message ----- From: Jefferson Smith To: Sent: Thursday, December 09, 2004 4:00 PM Subject: SPAM-LOW: [68HC12] Re: Flash programming from a bootloader 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 :) Yahoo! Groups Sponsor Get unlimited calls to U.S./Canada ------ Yahoo! Groups Links a.. To |
Flash programming from a bootloader
Started by ●December 8, 2004
Reply by ●December 9, 20042004-12-09
Reply by ●December 9, 20042004-12-09
ok, here's the whole ball of wax (what does that mean anyway?) I don't have any trouble writing to secure flash from RAM, but that is not to say I didn't have trouble getting there :-) The following code snippets are partially mine and partially from somebody on this list, sorry I cannot give credit to the original poster but I don't know who you are. Just as a bit of background and to answer 'Jeffs' statements, the bootloader resides in protected, secured flash memory at F000-FFFF and the incoming CAN messages are run from that memory space until the very last couple of commands where control is transferred to RAM. The bootloader copies the following code to RAM at a fixed address space (0x802 as you will see in the calling program) BTW, the chip is the S12C32 and does not come out of secure mode at any time. Because the bootloader is in protected flash memory, the 8000-EFFF (in this case) can be erased without fear of erasing the bootloader. X contains the flash memory location and Y contains the 16 bit data word, B contains the command. The machine code is show to the right // STY 0,X 6D00 // STAB 106 7B0106 // BSET 105 #80 1C010580 // NOP A7 // NOP A7 // NOP A7 // NOP A7 // NOP A7 // BRCLR 105 #40 1F010540FB // RTS 3D The calling code looks like this unsigned int GAddr,GData; unsigned char Flash_Wr ( unsigned int addr, unsigned int data ) { GAddrdr; // this has to do with how ICC12 handles varibles passed to inline assembly GDataa; if (( FCLKDIV & 0x80 ) ==0) FCLKDIV = 40; // WRITE CLOCK DEVIDER FCNFG = 0; asm("pshx"); asm("pshy"); asm("pshb"); asm("ldx _GAddr"); // store addr word for ram routine to use asm("ldy _GData"); // store data word for ram routine to use asm("ldab #0x20"); // command for program word asm("jsr $802"); // jump to ram routine HARDCODED ADDRESS asm("pulb"); asm("puly"); asm("pulx"); if (FSTAT & 0x20) { FSTAT = 0x20; return(2); } if (FSTAT & 0x10) { FSTAT = 0x10; return(3); } return 0; } ok, there you have it, now, how many of you have already done the google search on whole ball of wax? :-) 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 2:42 PM Subject: Re: [68HC12] Re: Flash programming from a bootloader 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 Links a.. To |
Reply by ●December 10, 20042004-12-10
Steve, what you are doing is essentially what I am doing except I use the serial port. This morning I tried again to run the code from ram to program the Flash and it worked with no problems. So I can only assume that I misunderstood the reason for it failing the last time I tried this. Anyways..thanks for confirming that it was possible to do this. It gave me the incentive to try things again. -Dave ----- Original Message ----- From: Steve Letkeman To: Sent: Thursday, December 09, 2004 4:36 PM Subject: Re: [68HC12] Re: Flash programming from a bootloader ok, here's the whole ball of wax (what does that mean anyway?) I don't have any trouble writing to secure flash from RAM, but that is not to say I didn't have trouble getting there :-) The following code snippets are partially mine and partially from somebody on this list, sorry I cannot give credit to the original poster but I don't know who you are. Just as a bit of background and to answer 'Jeffs' statements, the bootloader resides in protected, secured flash memory at F000-FFFF and the incoming CAN messages are run from that memory space until the very last couple of commands where control is transferred to RAM. The bootloader copies the following code to RAM at a fixed address space (0x802 as you will see in the calling program) BTW, the chip is the S12C32 and does not come out of secure mode at any time. Because the bootloader is in protected flash memory, the 8000-EFFF (in this case) can be erased without fear of erasing the bootloader. X contains the flash memory location and Y contains the 16 bit data word, B contains the command. The machine code is show to the right // STY 0,X 6D00 // STAB 106 7B0106 // BSET 105 #80 1C010580 // NOP A7 // NOP A7 // NOP A7 // NOP A7 // NOP A7 // BRCLR 105 #40 1F010540FB // RTS 3D The calling code looks like this unsigned int GAddr,GData; unsigned char Flash_Wr ( unsigned int addr, unsigned int data ) { GAddrdr; // this has to do with how ICC12 handles varibles passed to inline assembly GDataa; if (( FCLKDIV & 0x80 ) ==0) FCLKDIV = 40; // WRITE CLOCK DEVIDER FCNFG = 0; asm("pshx"); asm("pshy"); asm("pshb"); asm("ldx _GAddr"); // store addr word for ram routine to use asm("ldy _GData"); // store data word for ram routine to use asm("ldab #0x20"); // command for program word asm("jsr $802"); // jump to ram routine HARDCODED ADDRESS asm("pulb"); asm("puly"); asm("pulx"); if (FSTAT & 0x20) { FSTAT = 0x20; return(2); } if (FSTAT & 0x10) { FSTAT = 0x10; return(3); } return 0; } ok, there you have it, now, how many of you have already done the google search on whole ball of wax? :-) 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 2:42 PM Subject: Re: [68HC12] Re: Flash programming from a bootloader 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 Links a.. To ------ Yahoo! Groups Links a.. To |