Forums

Flash programming from a bootloader

Started by dwild.geo December 8, 2004

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




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




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




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




--- 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


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



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 >
>



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



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



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 :)