LRAE not preloaded

[imajeff]

Remember all the hype saying that soon Freescale would ship certain MPU (i.e. MC9S12C32) preloaded with the LRAE bootloader (Load Ram And Execute)?

Well, did anybody ever explain why they changed their mind, because I am still wondering. I started trying to use `hc12mem`, a command tool for Linux that would help overcome the drawbacks of FSL not supporting D-Bug12. I found that this is yet another utility that was relying on the preloaded bootloader to be shipped:
' '
LRAE is available for a wide selection of HCS12 MCUs. Source code, S-record files and description can be obtained from Freescale as Application Note - AN2546. This bootloader is supposedly loaded into new HCS12 MCUs as last stage of factory processing, thus some "fresh" parts straight from Freescale should have this bootloader already in FLASH memory.
' '

This reminded me to ask again the question that I hear asked, but I never do hear answered:
Why is FSL no longer planning to preload anything with LARE? It seemed very practical because it would give us more options, but still never get in the way if we didn't need it (easy to quickly erase, or just ignore if the programmer detects and erases memory automatically).

And why not answer this:  Why not let us order a batch of MCU, and specify that we want LARE? Can we do that anywhere you know of?

Thanks, anyone with answers.

[Alban]

Hello Jeff,

I've got some answers to your questions.

Shipping devices with a LRAE can add several steps, so time... Therefore money.
Many customers want the devices ERASED, so, when they receive them, they just program them and that is finished.
For a production chain, every second (and fraction of) costs and adding the MASS ERASE in their chain is not what they wish for. Programming houses are actually always asking for ways to speed-up programming.

Having both available would mean having DISTINCT part numbers. This is physically possible but it also requires two test flows and twice the stock for distributors.

As TBDML is able to program any S12  for bottom dollars, I imagine FSL considered it was not necessary and that the end user could program the LRAE if necessary.

Cheers,
Alban.

[kef]

Alban,

I never saw ERASED part direct from distributor! All S12's had security byte programmed to $FE, ie not blank. All 912D60A's came with shadow word programmed for 16MHz. And all XDT512/256 were also not blank, all had security byte programmed to $FE. And in addition to not blank security byte, some first XDT512's had programmed one or two words in each bank of flash.

So I don't see how programming chain can save on MASS ERASE. Violating "don't write more bits" requirement and writing to not erased security word? Not use security?

Regards

Edward

[Alban]

Hi Edward,

For me, ERASED is ready to program and use. I should have been clearer.
There are also other hidden memory which is program to be able to trace EVERY SINGLE device.
(I don't talk about HC12, but S12 also. I didn't consider them in my former statement)

Having a secure device would be a pain as it requires multiple operations to unsecure, as you can't get in initially. Actually, from experience, I have seen that very few people do secure their part... I don't really know

By default, Security Words are $FF aren't they ?

Finally, I also believe that many programmers do violate the forbidden "write-more-zeros" rule.
However, you have to admit that Security Bytes are rarely written in the application, therefore the risk of overprogramming and wear-out is low.

Cheers,
Alban.

[imajeff]

At first I thought Edward was just playing around when pointing out that it was not really "erased". Now I realize this is the important point that nullifies the whole reasoning for not shipping all with LRAE!

Certainly many will not bother to secure their part, but that may be they are a smaller vendor who also does not insist that every "second" counts when mass-producing. If they are mass producing such that every second counts, then they are also the type taking the time to erase that Flash because they will also insist on properly securing their valuable IP!

Therefore, they can erase the code while erasing the FE. Thanks kef!

It is important to point out something else that some might not know when it comes to seriously securing the MCU. There are risks of a hacker (maybe in China) learning to momentarily force the MCU to not see the erased bits or not see the programmed bits. If you have "secured" your part by only making one of the two bits in the insecure state, then that method will unsecure your part!  We should not secure only by erasing that or programming the other bit. We both erase and write FD to ensure security.

Also, doesn't it take typically less time to erase one sector (256 bytes) than to mass-erase? In that case could it be faster to erase only sectors we need to changed, and not a bulk erase?

So Alban, hope you'll be convincing FSL now to start shipping it that way

[Alban]

Hello,

I will not bother. I explained that I did not agree and why.
Furthermore the benefit is admitted to be negligible and can easily solved by the user.

Of course I trust anyone can find a case that is not covered out of the box.

Alban.

[imajeff]

---

imajeff wrote:
Also, doesn't it take typically less time to erase one sector (256 bytes) than to mass-erase? In that case could it be faster to erase only sectors we need to changed, and not a bulk erase?

---

Of course it is 256 words not 256 bytes (hope I didn't throw anyone off)

[kef]

Hi Alban,

For me, ERASED is fully erased or blank. For S12/S12X erased or blank means all bytes of flash and eeprom are erased and read as all ones, $FF. And FSL always ships S12 and S12X parts not blank. Security byte is always programmed to $FE. I disagree with what you wrote previously:

Many customers want the devices ERASED, so, when they receive them, they just program them and that is finished.
For a production chain, every second (and fraction of) costs and adding the MASS ERASE in their chain is not what they wish for. Programming houses are actually always asking for ways to speed-up programming.

Mass erase or sector erase are indeed necessary because parts aren't blank by default. Erase may be not necessary only in two cases: a) you don't need chip security at all, b) you don't mind violating specifications. If I understand you, you are suggesting that overprogramming only once is OK. I'm surprised to hear this from freescaler. 

Speaking about security. Chips are unsecured in two cases: a) security bits are programmed to binary xxxxxx10 (for example security byte= $FE), and b) part is really blank (both, eeprom and flash are erased). It's the problem of programmer/debugger tool if it's unable to program really blank parts.

Regards

Edward

[Alban]

Good Evening,

Quote for kef:
"
If I understand you, you are suggesting that overprogramming only once is OK. I'm surprised to hear this from freescaler.
"

Well, read more carefully and you won't get any element of surprise.
I did not say that at all. I talked about RISK and NEVER suggested you should do it !

Alban.

[kef]

Alban,

---

Alban wrote:

Quote for kef:
"
If I understand you, you are suggesting that overprogramming only once is OK. I'm surprised to hear this from freescaler.
"

Well, read more carefully and you won't get any element of surprise.
I did not say that at all. I talked about RISK and NEVER suggested you should do it !

Alban.

---

I wrote previously, that *if I understand you*, you are suggesting that overprogramming only once is OK. I'm surprised to hear this from freescaler. OK reading it again:
 

---

Finally, I also believe that many programmers do violate the forbidden "write-more-zeros" rule.
However, you have to admit that Security Bytes are rarely written in the application, therefore the risk of overprogramming and wear-out is low.

---

 

Maybe I'm stupid, but I still see in your words suggestion to write security byte twice without erase. This is of course against the docs, even if user would have to overprogram it or "write-more-zeros" just once. You wrote that the risk is low. Really? Even using overprogrammed device at marginal temps? Would you bet?

I didn't want to upset you. I agree with your other suggestions about cost of programming LRAE, about possible drawbacks of creating new numbers, or that it could be better to build at home TBDML. All is right. But excuse me, but this speculation about the erased devices and time needed to mass erase LRAE.. I couldn't resist to argue this. You didn't accept my argument and wrote more weird things:

Having a secure device would be a pain as it requires multiple operations to unsecure, as you can't get in initially. Actually, from experience, I have seen that very few people do secure their part... I don't really know

1) Blank device isn't secured device. 2) I *can* get in to blank devices initially. 3) Of course it's a pain for example for Multilink + CW. I don't know why these are unable to connect to *not secured* *blank* devices. Devices with the most bytes erased but security byte not blank ($FE), are not blank devices.

It's also surprising that very few people do secure their parts. But you should know better. Of course chip security is a pain in the ass for developers. But after software is done, only few manufacturers should keep their devices open. It doesn't cost anything to make security on but could prevent the theft.

It's a pity you will not bother. I wouldn't mind if you rolled this thread back to your initial message and edited it. I would rate your message 5 and didn't put my cents in later. This could rise a bit the value of forums archive. Hope imajeff wouldn't mind too.

Best Regards

Edward

[Alban]

Hello Edward,

I was in training and did not reply to the Community on that.

I would like to stress that the fact that I don't agree does not mean that you cannot ask for it !
I have absolutely no power whatsoever about the LRAE is inside a MCU or not, but, as customers, you all do. Devices are designed based on customer demand.

The best way to do so is to enter a Service Request or suggest it in the comment field of a SR that is closed (we receive a survey after 30 days).
Or even better, if you explain to your distributor why this is very important for you, they will go back to FSL as well.

---

About SEC bits:
I did not want to sound agressive/upset, I will adapt my language from now on. I prefer not to edit post content already replied to.
Yes, personally, I would bet. The data retention and cycling capacity is a compromise. It is the more you write/erase, the more the retention goes down. On the other hand, if you refresh a value often, you can write more times. Also, that location is not critical to the device execution.
However that is out of specification and that is up to the user to assess what he is willing to risk, or not.

Also, I think I may have an idea why little people secure their device. Secure devices are difficult in case of quality return/failure analysis.
If you take a fully open device that hanged, you hot-plug a BDM cable and you know what is going on.
In the case of a secure device, you need to launch an internal unsecuring mechanism before being able to see the state of the MCU. By that time, your fault might have disappeared.

I use the TBDML to debug and need to use the unsecure command file when I get a mass erased device. May you please tell us which tools you are using ? I'm interested in knowing and maybe try.

Regards,
Alban.

[kef]

Alban,

thanks for reminder that customers are important and how to SR, but I'm not that one who was asking for factory preloaded LRAE. Your point about risks and keeping security off is fine; diving into details could drag tens of Re's probably :smileyhappy:.

Tools you asked about is hc12-s12-s12x flash/eeprom programmer hardware+software I designed years ago for company I'm working at. Unsecure command is only needed for programmed and secured parts. Unsecure isn't required for blank parts (security byte = 0xFF) even after reset. Everything was done following Motorola/FSL docs.

Regards

[imajeff]

But Edward,

You mentioned that vendors would want the part shipped completely ERASED, meaning it would be in a secure state. I think they would have a hard time trying to program a secured chip without going through extra steps to program it.

How long does it take to go through all the steps of unsecuring it before it can be programmed?

[kef]

Jeff,

Unsecured parts are not only those with security bits programmed to 10, but also blank parts. Check BDM BDMSTS register UNSEC bit description. I don't know why some debuggers have problems connecting to blank parts. I wouldn't mind fully erased parts from the factory, my BDM programmer connects and programs sych parts well.

Regards

[imajeff]

Edited: kef, I didn't see your point, but maybe the numbers I calculate below show that you've got something anyway..
 (reading S12BDMV4.pdf). Your point is that we could save the fraction of a second per unit if we were not required to erase flash. If I understand your point about BDMSTS, you are saying that if it were completely erased, you can "just program" without having to do anything else first because BDM knows the chip is blank.

My point is that it would still require significant time for the "secure BDM firmware" to verify that all Flash and EEPROM is blank and then unsecure the device. It does not automatically know it is blank:
' '
The secure BDM firmware lookup table verifies that the on-chip EEPROM and FLASH EEPROM are erased. This being the case, the UNSEC bit is set and the BDM program jumps to the start of the standard BDM firmware lookup table and the secure BDM firmware lookup table is turned off.
' '

Thanks for pointing me to BDM documentation. Seeing that two issues are either erasing or unsecuring (verifying erased), I decided to compare times for yours and my ideas.

I calculate that to unsecure a DP512 using maximum clock (25 MHz), the erase-verify time is at least 10.9 mS.

I have mentioned that to bulk-erase one Flash block (over 100 mS) takes much longer than one 512-byte sector (20 to 26.7 mS). If I take the time to erase two sectors (LRAE and security bits), it is faster than bulk. If I've added 20 mS per target in mass production, because I'm erasing the LRAE sector, I'm adding 3.33 minutes per 10,000 units.

I do see that having to erase only the security sector can take almost twice as long as just verifying the device is blank (this is not considdering possible errata). So the vendors who mass produce with DP512 could be saving something like 0.009 per MCU (90 seconds per 10,000 units).

Check if I messed up the math, I often scramble something if I don't verify it.





Message Edited by imajeff on 2007-08-24 04:24 PM

[kef]

imajeff wrote:

Edited: kef, I didn't see your point, but maybe the numbers I calculate below show that you've got something anyway..
 (reading S12BDMV4.pdf). Your point is that we could save the fraction of a second per unit if we were not required to erase flash. If I understand your point about BDMSTS, you are saying that if it were completely erased, you can "just program" without having to do anything else first because BDM knows the chip is blank.

Jeff, I'm not interested in LRAE preinstalled or in really blank parts from the factory. FSL could change something in this aspect, preprogram LRAE or something else, I wouldn't mind because due to not blank security byte I always erase every part at least once.

I wasn't suggesting saving fraction of second. Alban said that LRAE isn't installed to save someone time needed to erase LRAE. My point is that with corrent no LRAE but not blank security byte - erase is still required.

Regarding BDMSTS. Yeah, I can just program fully erased parts without doing enything else.

My point is that it would still require significant time for the "secure BDM firmware" to verify that all Flash and EEPROM is blank and then unsecure the device. It does not automatically know it is blank:
' '
The secure BDM firmware lookup table verifies that the on-chip EEPROM and FLASH EEPROM are erased. This being the case, the UNSEC bit is set and the BDM program jumps to the start of the standard BDM firmware lookup table and the secure BDM firmware lookup table is turned off.
' '

You are absolutely right, erase verify takes quite a lot of time. I missed it.

When you mentioned the time needed to unsecure blank part, I thought about something else: In order to connect to blank part with (for example) P&E Multilink pod, it's necessary to run Unsecure12 utility or something like that. Of course it takes a lot of time to unsecure back to $FE in security byte. (time to start utility, time to press some buttons :smileyhappy:, time to reset and erase verify, etc). That's what I thought then. So I wrote about not secured blank parts. Of course erase verify also takes time, thanks.

...
... 3.33 minutes per 10,000 units...

... 0.009 per MCU (90 seconds per 10,000 units).

Check if I messed up the math, I often scramble something if I don't verify it.

Wow, what a dramatic savings. I believe your math is OK. But what about time needed to power up the target board and to let oscilator and everything else stabilize?

Regards

[imajeff]

Thanks Al, I was hoping you'd have a good answer : )

That was the guess I went with. I even explained to others that we shouldn't expect them to do it. I had figured there might be too much added cost. I was only hopeful that Freescale was smart enough to figure how without that. I guess I was more interrested in this for VSB, or students. That's why I see the actual bootloader as practically useless, but maybe there is still preloading vendors? If schools could order Q 100 and ask for them preloaded with LRAE, then students could be building kits that are just a target board with serial port, and not build both a target and a TBDML.

I think you are right, TBDML should be preferred. It's just that the overwhelming response to my claim has been that having only one board is more important. You may have seen people tell me that on other discussions here.

And yes I am not surprised that I got the worst rating possible for my question. I'm sure it's a misunderstanding; people seem to misunderstand, either way. That's why some people don't fight for what they believe--they are afraid of being publicly crushed.