I'm not sure that a separate program will work well in a development environment. There is a "run" button in SimpleIDE that downloads a program to the chip and starts it running. We wouldn't want to have to write the generated program to a file and then run a Qt app to sign it on every download. I think it's important for the loader to be able to at least sign images with a default key during development. Signing with a real key for generating production images could be handled by this Qt app. Does that make sense?
David, it is certainly possible to integrate signing into the loader, I don't have access to the loader and can't really speak for Parallax on whether it *will* do anything in particular. I know what the needs are for the chip and how to achieve those. Steve Denson is the author of SimpleIDE and I have the ability to contribute to that program, but sometimes people don't want additional dependencies introduced (such as having OpenSSL), for good reasons. Having a separate command line program that does all the heavy lifting, can solve much of the dependency issue and make a single tool that works with any IDE or loader. It means a small amount more work to open a pipe and send the data to the signing program, then get the results. I think this amount of work is less complex for someone who hasn't worked with OpenSSL, than writing code to use the OpenSSL library API directly.
David, it is certainly possible to integrate signing into the loader, I don't have access to the loader and can't really speak for Parallax on whether it *will* do anything in particular. I know what the needs are for the chip and how to achieve those. Steve Denson is the author of SimpleIDE and I have the ability to contribute to that program, but sometimes people don't want additional dependencies introduced (such as having OpenSSL), for good reasons. Having a separate command line program that does all the heavy lifting, can solve much of the dependency issue and make a single tool that works with any IDE or loader. It means a small amount more work to open a pipe and send the data to the signing program, then get the results. I think this amount of work is less complex for someone who hasn't worked with OpenSSL, than writing code to use the OpenSSL library API directly.
I wrote propeller-load so I know how to modify it to sign programs so that isn't a problem. I'm not sure why adding a dependency on libssl is a problem. The library can be packaged with the rest of PropGCC which already has lots of files. Alternatively, I could just do what Chip seems to be doing, roll my own.
Fedex International 3-day shipping? Meaning they might be at Parallax on the 12th?
I don't know, Jeff, but it'll be here quickly based on history. Taiwan is only 12 hours away and our packages hardly take 24 hours to arrive. I'd provide a tracking number but I think my crew might already be a little nervous about the fact I shared a packing list.
I don't know, Jeff, but it'll be here quickly based on history. Taiwan is only 12 hours away and our packages hardly take 24 hours to arrive. I'd provide a tracking number but I think my crew might already be a little nervous about the fact I shared a packing list.
The fish-hook is the delay from clk to data change, is spec'd at more than one nominal Prop clk, and you do not want to ever be right on that change.
Clocking the data in on the high going clock should work perfectly. It's your typical fully synchronous clocking trick - make use of hold-off. There is a 15ns minimum hold-off (t2) on the previous data before any chance of a transition to the new data appearing on mdat. In this case it means you have to have cycled the clock line at least one whole cycle prior to taking first bit-sample.
But that's only for the bus interface. For the whole ADC sampler it will likely require many more preceding clocks to start getting a stable reading anyway.
My understanding is I can permanently feed up to a 20 MHz regular clock at the AD7401 and it'll work a treat.
Clocking the data in on the high going clock should work perfectly. It's your typical fully synchronous clocking trick - make use of hold-off. There is a 15ns minimum hold-off (t2) on the previous data before any chance of a transition to the new data appearing on mdat.
Correct, but the Prop does not have a Slave D-FF, which is what "Clocking the data in on the high going clock " dictates. Instead, it samples the pins at 12.5ns intervals.
However, it does have the LOGIC mode I mentioned, which avoids the Data edge, ever getting close to a Prop sample point.
Not that I want to contribute to non Prop2 info
But here is 20MHz, Second-Order, Isolated Delta-Sigma Modulator for Current-Shunt Measurement (As TI bough Analog, not sure if these products will merge) http://www.ti.com/lit/ds/sbas512c/sbas512c.pdf
Everybody here appreciates an inside look at what's going on in Parallax, so maybe you'd be interested in this message in my e-mail this morning. - Ken
I don't know, Jeff, but it'll be here quickly based on history. Taiwan is only 12 hours away and our packages hardly take 24 hours to arrive. I'd provide a tracking number but I think my crew might already be a little nervous about the fact I shared a packing list.
Hopefully you will have them in hand before the opposition works out what flight they are on
Oooh the suspense is killing.... Add a couple of hours after they arrive and we may know something - everything crossed
Edit: It just occured to me that I just spent the last 15 minutes tracking down data on Erco's Russian designer in the General thread, now I'm tracking international flights.. Am I in trouble here?
The chips are supposed to be at Parallax by 10:30am tomorrow.
I've talked to David Carrier about what to do with them. He's going to solder four chips onto breakout boards and then check internal continuity on the chip's power supply pins, then make sure the power rails are not shorted together. If that tests out, he will power up the supplies with a current-limit of 50ma. BOEn will be held high and RESn will be pulled high. After pulling RESn low temporarily, he will look for toggling on the SCLK pin that normally goes out to a flash EEPROM (on P86..P89 - I can't remember which). If there is toggling, the chip is alive. If not, we have a show-stopping problem. If there is toggling, that also means the monitor should be functional, so David will see if he can get a monitor prompt over the P91/P90 serial connection. If all that works, we should be able to download a program with PNUT, by signing it using a key of 128 zero bits.
If David sees any signs of life, I'll be driving down to Rocklin to see what all we can get the chip to do. It sure would be great if it works. If it doesn't... we'll have to figure out why, somehow. I'll be really relieved if it just works.
Thanks for all your interest, best wishes, and prayers!
. If that tests out, he will power up the supplies with a current-limit of 50ma. BOEn will be held high and RESn will be pulled high. After pulling RESn low temporarily, he will look for toggling on the SCLK pin
Wouldn't you more commonly hold RESn low, then release at some rising Vcc point ?
Are the breakout boards all pre-assembled, and how much control do you have over the VccCore ?
In testing ES devices, I've found it illuminating to vary the Vcc - sometimes things work at different ranges.
For 'killer tests', a slow function generator that ramps Vcc but above Zero, can uncover all sorts of 'no mans land' issues.
Another useful sign of life indicator, is a radio receiver or spectrum analyser, looking for the on-chip Oscillators and PLLs
Wouldn't you more commonly hold RESn low, then release at some rising Vcc point ?
Are the breakout boards all pre-assembled, and how much control do you have over the VccCore ?
In testing ES devices, I've found it illuminating to vary the Vcc - sometimes things work at different ranges.
For 'killer tests', a slow function generator that ramps Vcc but above Zero, can uncover all sorts of 'no mans land' issues.
Another useful sign of life indicator, is a radio receiver or spectrum analyser, looking for the on-chip Oscillators and PLLs
If the power supplies are stable and we reset the chip, it should boot up. Keeping the brown-out detector 'off' will keep things simpler.
These are simple breakout boards that just bring all the pins to header holes.
We'll vary the VDD later, but first we just need to see if it works at 1.8V.
If we see nothing on the SCLK pin, we'll start feeding VDD through a 100 ohm resistor and see if we can see any modulation on the chip-side VDD after a reset, which would indicate logic sequencing. Cog0 should try to boot if the logic is connected properly, never minding the memories.
However, it does have the LOGIC mode I mentioned, which avoids the Data edge, ever getting close to a Prop sample point.
Ok but still want to be reading on the high going - LOGIC A & B. Both the Prop's clock and the 10MHz clock are from the same source of course. It would be silly to have a separate clock source.
Comments
David, it is certainly possible to integrate signing into the loader, I don't have access to the loader and can't really speak for Parallax on whether it *will* do anything in particular. I know what the needs are for the chip and how to achieve those. Steve Denson is the author of SimpleIDE and I have the ability to contribute to that program, but sometimes people don't want additional dependencies introduced (such as having OpenSSL), for good reasons. Having a separate command line program that does all the heavy lifting, can solve much of the dependency issue and make a single tool that works with any IDE or loader. It means a small amount more work to open a pipe and send the data to the signing program, then get the results. I think this amount of work is less complex for someone who hasn't worked with OpenSSL, than writing code to use the OpenSSL library API directly.
Is there no way to use needle probes directly on the wafer?
It would require more needle probes than we have.
Thanks,
David
I don't know, Jeff, but it'll be here quickly based on history. Taiwan is only 12 hours away and our packages hardly take 24 hours to arrive. I'd provide a tracking number but I think my crew might already be a little nervous about the fact I shared a packing list.
Someone needs to get Chip a case of coffee, Mountain Dew and Jolt cola. And a never ending supply of pizza...
C'mon Chip, sleep is for wimps...
Bean
Clocking the data in on the high going clock should work perfectly. It's your typical fully synchronous clocking trick - make use of hold-off. There is a 15ns minimum hold-off (t2) on the previous data before any chance of a transition to the new data appearing on mdat. In this case it means you have to have cycled the clock line at least one whole cycle prior to taking first bit-sample.
But that's only for the bus interface. For the whole ADC sampler it will likely require many more preceding clocks to start getting a stable reading anyway.
My understanding is I can permanently feed up to a 20 MHz regular clock at the AD7401 and it'll work a treat.
Hehe, stresssSSS ...
Correct, but the Prop does not have a Slave D-FF, which is what "Clocking the data in on the high going clock " dictates. Instead, it samples the pins at 12.5ns intervals.
However, it does have the LOGIC mode I mentioned, which avoids the Data edge, ever getting close to a Prop sample point.
Yes, but I'd avoid jitter on the MCLK, and 10MHz (jitter free) is at the centre of the spec range.
We still do not know if Prop 2 has a EXTCLK, CLKEN ability, but it should still have the LOGIC modes ?
But here is 20MHz, Second-Order, Isolated Delta-Sigma Modulator for Current-Shunt Measurement (As TI bough Analog, not sure if these products will merge)
http://www.ti.com/lit/ds/sbas512c/sbas512c.pdf
Oooh the suspense is killing.... Add a couple of hours after they arrive and we may know something - everything crossed
http://flightaware.com/live/fleet/FDX
Maybe? http://flightaware.com/live/airport/VHHH
Anyone want to help me pair this down a little..
Edit: It just occured to me that I just spent the last 15 minutes tracking down data on Erco's Russian designer in the General thread, now I'm tracking international flights.. Am I in trouble here?
I've talked to David Carrier about what to do with them. He's going to solder four chips onto breakout boards and then check internal continuity on the chip's power supply pins, then make sure the power rails are not shorted together. If that tests out, he will power up the supplies with a current-limit of 50ma. BOEn will be held high and RESn will be pulled high. After pulling RESn low temporarily, he will look for toggling on the SCLK pin that normally goes out to a flash EEPROM (on P86..P89 - I can't remember which). If there is toggling, the chip is alive. If not, we have a show-stopping problem. If there is toggling, that also means the monitor should be functional, so David will see if he can get a monitor prompt over the P91/P90 serial connection. If all that works, we should be able to download a program with PNUT, by signing it using a key of 128 zero bits.
If David sees any signs of life, I'll be driving down to Rocklin to see what all we can get the chip to do. It sure would be great if it works. If it doesn't... we'll have to figure out why, somehow. I'll be really relieved if it just works.
Thanks for all your interest, best wishes, and prayers!
I really hope the ICs work! : ]
Wouldn't you more commonly hold RESn low, then release at some rising Vcc point ?
Are the breakout boards all pre-assembled, and how much control do you have over the VccCore ?
In testing ES devices, I've found it illuminating to vary the Vcc - sometimes things work at different ranges.
For 'killer tests', a slow function generator that ramps Vcc but above Zero, can uncover all sorts of 'no mans land' issues.
Another useful sign of life indicator, is a radio receiver or spectrum analyser, looking for the on-chip Oscillators and PLLs
If the power supplies are stable and we reset the chip, it should boot up. Keeping the brown-out detector 'off' will keep things simpler.
These are simple breakout boards that just bring all the pins to header holes.
We'll vary the VDD later, but first we just need to see if it works at 1.8V.
If we see nothing on the SCLK pin, we'll start feeding VDD through a 100 ohm resistor and see if we can see any modulation on the chip-side VDD after a reset, which would indicate logic sequencing. Cog0 should try to boot if the logic is connected properly, never minding the memories.
They are completely generic.
Enjoy!
Mike
Ok but still want to be reading on the high going - LOGIC A & B. Both the Prop's clock and the 10MHz clock are from the same source of course. It would be silly to have a separate clock source.
/Johannes
I'll second this notion.....