Were the pads reworked to resolve the latchup "problem"? I can't recall. Problem in quotes because latchup only occurs well above spec.
Will Rev. C Eval boards be available? Hoping to have a full collection
We did not put the guard rings around certain n-wells because it would have been a very expensive all-layer change. We're just going to rate the part for 4.0V, absolute max.
I did not see injection current levels specified for latchup ? - Just a lowering of the Abs Max Vcc value ?
Other vendors spec their MCUs like this
VHBM[*1] Electrostatic discharge,human body mode -8000 - +8000 V
VCDM[*2] Electrostatic discharge,charge device model -1000 - +1000
LU[*3] Pin current for latch-up[*3] -400 - +400 mA
VEFT[*4] [*5] Fast transient voltage burst -4.4 - +4.4 kV
To celebrate, Ken has put the P2-ES Eval Rev B boards and the P2-ES Rev B 4-packs on sale:......
Does that mean that the “One Eval Board per customer” restriction has been rescinded?
Yes, please buy what you'd like! Multiple boards per customer are now allowed since we've been able to put at least one in the hands of each interested developer [who expressed interest in the P2].
Will Rev. C Eval boards be available? Hoping to have a full collection
If you're really going to have a full collection you'll have to get someone to sell you one of the ultra rare glob top boards.
There was both revA and revB editions of those. I have a revB. I don't think Chip gave out any of the revA glob-tops.
IIRC there were only 10 glob top Rev A chips. One got drilled/destroyed by Chip during assembly of the first board(s)
I think they were only built on Peter's P2D2 Rev1 boards, not the P2-EVAL boards which were not done at the time.
Peter J and I have RevA glob tops because we needed to verify our ROM code. I think one may have gone to the Melbourne guys.
Peter may have put a couple on the first P2D2's he built??
So, out of 10, 1 destroyed, 1 each to Chip, Peter, myself, and melbourne. So 5 whereabouts unknown.
BTW I won't be selling mine.
FWIW there were ~120 Rev A with production packaging.
So, out of 10, 1 destroyed, 1 each to Chip, Peter, myself, and melbourne. So 5 whereabouts unknown.
Two ended up down here, and sadly the good smoke escaped out of both of them.
The cause was a nasty firmware bug in a bench top supply that changed ranges from 5V to 36V.
Were the pads reworked to resolve the latchup "problem"? I can't recall. Problem in quotes because latchup only occurs well above spec.
Will Rev. C Eval boards be available? Hoping to have a full collection
We did not put the guard rings around certain n-wells because it would have been a very expensive all-layer change. We're just going to rate the part for 4.0V, absolute max.
I did not see injection current levels specified for latchup ? - Just a lowering of the Abs Max Vcc value ?
Other vendors spec their MCUs like this
VHBM[*1] Electrostatic discharge,human body mode -8000 - +8000 V
VCDM[*2] Electrostatic discharge,charge device model -1000 - +1000
LU[*3] Pin current for latch-up[*3] -400 - +400 mA
VEFT[*4] [*5] Fast transient voltage burst -4.4 - +4.4 kV
ON ran their standard latch-up test and the P2 passed. Let me see if I can find the results...
@cgracey, in the docs for the wrpin mode TT bits it says this:
for all smart pin modes (%MMMMM > %00000):
x0 = output disabled, regardless of DIR
x1 = output enabled, regardless of DIR
In my testing with pwm_triangle and pwm_sawtooth modes, I found that the output would be driven once I raised DIR even if TT = 00.
Either I don't understand something, or the docs are not complete/correct.
I was thrown off by the extra 0 in the bottom bit. /sigh sorry.
Cool, I couldn't compile your example anyway. My Fastspin was out of date for C support and when updated it couldn't find a certain libc/unix/bufio.c file. I'm guessing the spin2cpp master tree is in limbo, atm. I'll probably have to build it from the FlexGUI master sources instead.
evenh,
Yeah the current spin2cpp code in github is missing the bufio.c file, I just made one with stub functions to get it to compile. I also have local changes/fixes that are waiting in pull requests for Eric's return.
If you still have the code you can see that I was setting mode to 0x00000050 which indeed sets the TT bits to 01. I was mentally shifting it because of the unused bottom bit.
Ugh! Chip, why does BMASK have that +1 to S operand? I keep having to -1 to my parameters. And it would've been convenient for me if a value of zero meant no bits getting set.
EDIT: Funnily, I've managed to minimise the impact. It's a good reference for future similar cases:
'64-bit summation truncated to 32-bit with a chosen bit-shift parameter
bmask pa, .gain 'setup number of high bits to shift down
shr pa, #1 'compensate for BMASK's offset
setq pa
muxq .firval, .firval2 'move high bits
ror .firval, .gain 'rotate them to high bit positions
Ugh! Chip, why does BMASK have that +1 to S operand? I keep having to -1 to my parameters. And it would've been convenient for me if a value of zero meant no bits getting set.
EDIT: Funnily, I've managed to minimise the impact. It's a good reference for future similar cases:
'64-bit summation truncated to 32-bit with a chosen bit-shift parameter
bmask pa, .gain 'setup number of high bits to shift down
shr pa, #1 'compensate for BMASK's offset
setq pa
muxq .firval, .firval2 'move high bits
ror .firval, .gain 'rotate them to high bit positions
It just does what the same PASM instruction does. I could make it like you want, but I'd have to give it another name. Any ideas? BITMASK?
Ah, I am talking about pasm/machine code. Just seems the wrong way to me is all. No biggie, applying the post-op shifting compensation is a short simple fix which also provides the null I was after too.
Ah, I am talking about pasm/machine code. Just seems the wrong way to me is all. No biggie, applying the post-op shifting compensation is a short simple fix which also provides the null I was after too.
All the instructions which deal with bits have been harmonized to use S[4:0] or D[4:0] as the bit chooser to avoid ambiguity that would have come from incorporating higher bits in the process.
Right, I did notice the commonality. In hindsight, making them all with S=0 producing a null effect would have been better, imho.
I know, but then that would have required one more bit to accommodate the ADDPINS/ADDBITS field and rendered the 32..63 values all same. For many things, it would have just necessitated extra code to handle the edge case. There was no clear win here.
... that would have required one more bit to accommodate the ADDPINS/ADDBITS field ...
Oh, that's just sunk in. Zero value is one pin. Ha, I was always thinking of that as an optional field. Yeah, I see what you mean, that effect is true for all those encoded fields, so can't have both ways.
Comments
I did not see injection current levels specified for latchup ? - Just a lowering of the Abs Max Vcc value ?
Other vendors spec their MCUs like this
How much process variation are you seeing in a new batch ?
are leakage, mA/MHz and maximum SysCLK significantly different, or ~exactly the same ?
Yes, both those restrictions have been lifted for around a month
Yes, please buy what you'd like! Multiple boards per customer are now allowed since we've been able to put at least one in the hands of each interested developer [who expressed interest in the P2].
Ken Gracey
I think they were only built on Peter's P2D2 Rev1 boards, not the P2-EVAL boards which were not done at the time.
Peter J and I have RevA glob tops because we needed to verify our ROM code. I think one may have gone to the Melbourne guys.
Peter may have put a couple on the first P2D2's he built??
So, out of 10, 1 destroyed, 1 each to Chip, Peter, myself, and melbourne. So 5 whereabouts unknown.
BTW I won't be selling mine.
FWIW there were ~120 Rev A with production packaging.
Two ended up down here, and sadly the good smoke escaped out of both of them.
The cause was a nasty firmware bug in a bench top supply that changed ranges from 5V to 36V.
Well, we've got TWO P2 Eval boards with Rev C silicon on them. That's it, at this point. I haven't done any measuring.
ON ran their standard latch-up test and the P2 passed. Let me see if I can find the results...
Bill M.
It's all the same. Just a resistor within the ADC mux was disconnected to stop noise coupling.
EDIT: Maybe just the ADC ... P=%100_010_xxxxxxx
Right. Now, if you select that mode, you can measure the zero-bias point of the ADC, which is potentially useful for measuring very small currents.
in the docs for the wrpin mode TT bits it says this:
for all smart pin modes (%MMMMM > %00000): x0 = output disabled, regardless of DIR x1 = output enabled, regardless of DIRIn my testing with pwm_triangle and pwm_sawtooth modes, I found that the output would be driven once I raised DIR even if TT = 00.Either I don't understand something, or the docs are not complete/correct.
I was thrown off by the extra 0 in the bottom bit. /sigh sorry.
Yeah the current spin2cpp code in github is missing the bufio.c file, I just made one with stub functions to get it to compile. I also have local changes/fixes that are waiting in pull requests for Eric's return.
If you still have the code you can see that I was setting mode to 0x00000050 which indeed sets the TT bits to 01. I was mentally shifting it because of the unused bottom bit.
EDIT: Funnily, I've managed to minimise the impact. It's a good reference for future similar cases:
It just does what the same PASM instruction does. I could make it like you want, but I'd have to give it another name. Any ideas? BITMASK?
All the instructions which deal with bits have been harmonized to use S[4:0] or D[4:0] as the bit chooser to avoid ambiguity that would have come from incorporating higher bits in the process.
I know, but then that would have required one more bit to accommodate the ADDPINS/ADDBITS field and rendered the 32..63 values all same. For many things, it would have just necessitated extra code to handle the edge case. There was no clear win here.
I do not think so.