The New 16-Cog, 512KB, 64 analog I/O Propeller Chip

Comments

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

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.

"We suspect that ALMA will allow us to observe this rare form of CO in many other discs. By doing that, we can more accurately measure their mass, and determine whether scientists have systematically been underestimating how much matter they contain."

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?

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.

"We suspect that ALMA will allow us to observe this rare form of CO in many other discs. By doing that, we can more accurately measure their mass, and determine whether scientists have systematically been underestimating how much matter they contain."

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.

The fuse problem was known for a while now. And apparently is common for low voltage parts under 5 Volts like this.

"We suspect that ALMA will allow us to observe this rare form of CO in many other discs. By doing that, we can more accurately measure their mass, and determine whether scientists have systematically been underestimating how much matter they contain."

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

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.

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.

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

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.