IMHO this will mean only the most hardened customers will use fuses. Many customers will consider the P2 a failed chip with this impediment, and won't even use it even if they don't want the fuses anyway. At least that's the way I would consider it if I were considering the P2 in a commercial design.
On the other hand, there are those commercial applications that absolutely require some security such as fuses. And P2 would be bypassed in those.
It's real enough as far as the scope is concerned. But that's only due to the inductance of the scope lead and the oscillating potential differences across it. And it's not what the Prop itself sees relative to its own PCB ground plane.
The attached image shows the difference. In the left-hand pair of images, a standard ground clip is used to probe the Prop's P3 pin, which is outputting a square wave. You can see the overshoot. In the right-hand pair, the ground lead is removed from the scope probe and replaced with a very short length of bare wire. The overshoot all but disappears. It's even better to solder the short wire directly to the PCB.
Is code protect so vital? If our implementation is so troublesome, what if we just didn't have it?
Depends on your value of 'vital' I guess ?
IIRC Ken has rated security up near the top of the P1+ lists.
If OnSemi OTP is not viable for some reason, alternatives for handling what you have now could be
* To factory code a random ID number, so every chip is serialised, that ID number can be used to lock.
Possibly also a date code for batch-type security ?
This does not need special tracking codes or labeling.
* To offer factory Locking to some user provided full key - parts shipped 100% tested, in trays.
This does make each chip-lot unique, and needs some means of tracking/labeling.
@Phil I tightened up the gnd much like your photo, but still see a considerable overshoot (+ringing). I'm measuring on a Flip because I'm frankly more interested in the switchmode recovery, but will post pics and cro caps later - have a broken system that needs attention.
But backing up a step, most of the time probing one starts with the flying croc clip ground, and this added load and parasitics does indeed result in node voltages above 3v3, albeit briefly, and things still work after the probe is moved to some other unsuspecting node. Ie I think systems are more robust to (sub 5v) excursions than is bring portrayed here
Is there any alternative to the fuses actually up for offer?
There have been many who have asked for code protection. If OTP or whatever isn't an option then it's best to stick with the existing fuses and document a reliable procedure for popping them. Better that than nothing at all I'd think.
EDIT: After all, code-protection is a finished product exercise that has the single purpose of making the customer's life more difficult. Maybe it's a little karma.
Roy is spot on, I think.
About using a jumper - that doesn't sound feasible. How would that be handled for mass production? A robot inserting a jumper, then removing it? Are such things done in production lines?
Is there any alternative to the fuses actually up for offer?
OnSemi do have a range of Config-type memories.
The exact terms/die costs/interfaces have not been fully defined, but they do exist.
OTP you can expect to be the smallest and cheapest, with erasable cells next up the curve.
Chip,
I thought that code protection was extremely high on the list. IMHO another solution is required!
I am extremely disappointed that despite my urging, you haven't bothered to even ask about the other possible solutions such as flash/eeprom/OTP despite my continual urging to do so. Seriously, it's a real embarrassment to get to this stage and find out about the fuse problems now.
Chip,
I thought that code protection was extremely high on the list. IMHO another solution is required!
I am extremely disappointed that despite my urging, you haven't bothered to even ask about the other possible solutions such as flash/eeprom/OTP despite my continual urging to do so. Seriously, it's a real embarrassment to get to this stage and find out about the fuse problems now.
I'm sorry for my hesitation. I've been worried about process changes that likely accompany these other memory solutions. We really can't afford to redo everything at this point.
I've asked OnSemi to tell us today how big, in square mm, their smallest NV memory instance is that contains its own charge pump, so that there is no VPP pin requirement.
Full disclosure: I have no need or desire for code protection, but I would really hate to delay the P2 for this reason.
Biased opinion:
My own experience as an engineer that has literally shipped hundreds of millions of digital devices is that the <1% of customers who wanted to hack my products were going to be successful no matter what the safeguards.
... I've been worried about process changes that likely accompany these other memory solutions. We really can't afford to redo everything at this point.
I'm not sure there is anyprocess change for the OTP cells, from reading OnSemi's offerings.
There may be a small area impact.
It's very common for chips to need SOME level of config or cal, so these cells should be well proven - even lower risk than fuses..
I don't see why mass production could have either a header for programming that provided the 5V or a spring loaded programmer contact. For me I would put a miles connector that included the power on an extra pin.
Their EEPROM only requires the MiM cap option in the ONC18 process. An 8x32 bit instance would be 695um x 240um, which is small enough. No VPP pin needed. It runs off the core 1.8V supply. It has an expected 15-year data retention at 135 degrees Celsius.
The maximum bit array size is 16 bits x 64 words, or 1K bits. We only need 256 bits, of course.
So, this looks like it would solve the problem and allow easier development of a whole family of Prop2 chips, since we could always have the needed 256 bits of EEPROM without needing 64 I/O pins which each contain 4 fuses.
There is some mention about needing a very stable VREF input, which requires a bandgap reference with trimming bits of its own. I'm asking them about this now. This seems a little complicated.
Thanks, Cluso99 for your repeated prodding haranguing. You saved the day! Prop day. And don't worry about those rumors about messengers bearing bad news being killed; that's only if no solutions exist. **Update** Hmm...I may have spoken too soon. Well, perhaps there's still a OTP route if the EEPROM one doesn't work out.
Their EEPROM only requires the MiM cap option in the ONC18 process. An 8x32 bit instance would be 695um x 240um, which is small enough. No VPP pin needed. It runs off the core 1.8V supply. It has an expected 15-year data retention at 135 degrees Celsius.
The maximum bit array size is 16 bits x 64 words, or 1K bits. We only need 256 bits, of course.
There are no extra costs to use this.
We will use it.
Sounds very good, this is EEPROM too, not OTP ?
How many Erase cycles Endurance ? What size Erase ? Q : can it have a Write-Protect bit ?
Some forms of security want to prevent Trojan horse type attacks, where the Key and code are BOTH changed, and the product 'looks' the same ....
1k bits min is fine, as you want 256 bits plus calibrate storage for RC Osc's, plus unique serial number, plus some user space....
There is some mention about needing a very stable VREF input, which requires a bandgap reference with trimming bits of its own. I'm asking them about this now. This seems a little complicated.
Seems a little unusual, as most EEPROM cells are MOSFET threshold based, and that usually is sensed with another mosfet, given it varies with temperature.
Maybe that Vref sets a read current level ?
I expected OnSemi would have a solution. Bet they have a solution for larger blocks too!
Why don't you also ask about using eeprom/flash/otp to replace the little ROM too, or at least some of it?
Then the boot code could be changed too. I would modify the boot code to boot directly from SD without requiring a SPI Flash chip to boot.
If the SD boot code could be merged within the actual SPI Flash chip reading routines and still fit inside the limits of the ROM code, a single EEPROM bit could be used to select between them. Both worlds could fit into one solution.
I expected OnSemi would have a solution. Bet they have a solution for larger blocks too!
Why don't you also ask about using eeprom/flash/otp to replace the little ROM too, or at least some of it?
Then the boot code could be changed too. I would modify the boot code to boot directly from SD without requiring a SPI Flash chip to boot.
Comments
On the other hand, there are those commercial applications that absolutely require some security such as fuses. And P2 would be bypassed in those.
Cheers,
Peter (pjv)
It's real enough as far as the scope is concerned. But that's only due to the inductance of the scope lead and the oscillating potential differences across it. And it's not what the Prop itself sees relative to its own PCB ground plane.
The attached image shows the difference. In the left-hand pair of images, a standard ground clip is used to probe the Prop's P3 pin, which is outputting a square wave. You can see the overshoot. In the right-hand pair, the ground lead is removed from the scope probe and replaced with a very short length of bare wire. The overshoot all but disappears. It's even better to solder the short wire directly to the PCB.
-Phil
Depends on your value of 'vital' I guess ?
IIRC Ken has rated security up near the top of the P1+ lists.
If OnSemi OTP is not viable for some reason, alternatives for handling what you have now could be
* To factory code a random ID number, so every chip is serialised, that ID number can be used to lock.
Possibly also a date code for batch-type security ?
This does not need special tracking codes or labeling.
* To offer factory Locking to some user provided full key - parts shipped 100% tested, in trays.
This does make each chip-lot unique, and needs some means of tracking/labeling.
But backing up a step, most of the time probing one starts with the flying croc clip ground, and this added load and parasitics does indeed result in node voltages above 3v3, albeit briefly, and things still work after the probe is moved to some other unsuspecting node. Ie I think systems are more robust to (sub 5v) excursions than is bring portrayed here
Newer parts spec down as low as 4V ABS MAX.
There have been many who have asked for code protection. If OTP or whatever isn't an option then it's best to stick with the existing fuses and document a reliable procedure for popping them. Better that than nothing at all I'd think.
EDIT: After all, code-protection is a finished product exercise that has the single purpose of making the customer's life more difficult. Maybe it's a little karma.
About using a jumper - that doesn't sound feasible. How would that be handled for mass production? A robot inserting a jumper, then removing it? Are such things done in production lines?
OnSemi do have a range of Config-type memories.
The exact terms/die costs/interfaces have not been fully defined, but they do exist.
OTP you can expect to be the smallest and cheapest, with erasable cells next up the curve.
I thought that code protection was extremely high on the list. IMHO another solution is required!
I am extremely disappointed that despite my urging, you haven't bothered to even ask about the other possible solutions such as flash/eeprom/OTP despite my continual urging to do so. Seriously, it's a real embarrassment to get to this stage and find out about the fuse problems now.
The fuse problem was known for a while now. And apparently is common for low voltage parts under 5 Volts like this.
I'm sorry for my hesitation. I've been worried about process changes that likely accompany these other memory solutions. We really can't afford to redo everything at this point.
I've asked OnSemi to tell us today how big, in square mm, their smallest NV memory instance is that contains its own charge pump, so that there is no VPP pin requirement.
Let's see what they say.
Biased opinion:
My own experience as an engineer that has literally shipped hundreds of millions of digital devices is that the <1% of customers who wanted to hack my products were going to be successful no matter what the safeguards.
There may be a small area impact.
It's very common for chips to need SOME level of config or cal, so these cells should be well proven - even lower risk than fuses..
Their EEPROM only requires the MiM cap option in the ONC18 process. An 8x32 bit instance would be 695um x 240um, which is small enough. No VPP pin needed. It runs off the core 1.8V supply. It has an expected 15-year data retention at 135 degrees Celsius.
The maximum bit array size is 16 bits x 64 words, or 1K bits. We only need 256 bits, of course.
So, this looks like it would solve the problem and allow easier development of a whole family of Prop2 chips, since we could always have the needed 256 bits of EEPROM without needing 64 I/O pins which each contain 4 fuses.
There are no extra costs to use this.
We will use it.
We must thank Cluso99 for his prodding to check into this. I didn't think anything so simple was likely to exist.
Now how to resist thinking about what to use the remaining 768 bits for...
How many Erase cycles Endurance ? What size Erase ?
Q : can it have a Write-Protect bit ?
Some forms of security want to prevent Trojan horse type attacks, where the Key and code are BOTH changed, and the product 'looks' the same ....
1k bits min is fine, as you want 256 bits plus calibrate storage for RC Osc's, plus unique serial number, plus some user space....
Seems a little unusual, as most EEPROM cells are MOSFET threshold based, and that usually is sensed with another mosfet, given it varies with temperature.
Maybe that Vref sets a read current level ?
It is very common for Chips to need SOME programming, so such problems are likely to have been solved before
I expected OnSemi would have a solution. Bet they have a solution for larger blocks too!
Why don't you also ask about using eeprom/flash/otp to replace the little ROM too, or at least some of it?
Then the boot code could be changed too. I would modify the boot code to boot directly from SD without requiring a SPI Flash chip to boot.
If the SD boot code could be merged within the actual SPI Flash chip reading routines and still fit inside the limits of the ROM code, a single EEPROM bit could be used to select between them. Both worlds could fit into one solution.
Only a thought...
Henrique