EEVblog
Vložit
- čas přidán 24. 07. 2024
- David looks at the pins on the Padauk PMS150 programmer for potential reverse engineering.
TLDR; It doesn't look easy to reverse engineer this protocol, it's messy with lots of voltage levels, as Padauk said it would be.
Just buy the programmer for now!
There is also a Flash/EEPROM re-programmable version of the chip, the PFS154C.
Forum: www.eevblog.com/forum/blog/ee...
EEVblog Main Web Site: www.eevblog.com
The 2nd EEVblog Channel: / eevblog2
Support the EEVblog through Patreon!
/ eevblog
AliExpress Affiliate: s.click.aliexpress.com/e/c2LRpe8g
Buy anything through that link and Dave gets a commission at no cost to you.
Stuff I recommend:
kit.com/EEVblog/
Donate With Bitcoin & Other Crypto Currencies!
www.eevblog.com/crypto-currency/
T-Shirts: teespring.com/stores/eevblog
Likecoin - Coins for Likes: likecoin.pro/@eevblog/dil9/hcq3 - Věda a technologie
>Something vaguely technical / tedious
"Get young Dave to do it"
I've reverse-engineered protocols in the past. Once because the authors of the protocol said they were too busy to provide documentation, another time because the documentation was lost. There is a certain satisfaction to sleuthing such things out.
Especially so when the guy who hogs the docs is sitting in the office next door and brings up the topic a week later when you meet at the coffee machine and you just go: "Nevermind, I figured it out." :D
it seems a very tricky process tho, respect.
I would assume that the voltage level change on the clock and data pins has no significance, they just have to adjust the logic levels as they change the Vcc. I.e. if you run a cmos logic chip on 10v, the 0->1 transition will happen at 5v; whereas it will happen at 2.5v if you run it on 5v. If I were you, I would look inside that programmer; maybe some labels / resistors can give some hints.
If you were to have one analog channel on the rail and the rest digital from the 4000 series buffer I am guessing that is all you would need.
At 7:59 I think you're wrong. Rising edges are too close. I think data is read only on the falling edge. Create a sample program with a hex string of AA55AA55FF00FF00 then look for this data pattern. Thinking the slower clock cycles are the required time to burn each byte of data. Keep up the good work.
Yeah, falling edge seems more likely but there is quite some time between the data rising and the rising clock edge.
The data is pretty stable once the first rising edge is encounter, there isn't any overlap.
What your seeing here is just uncompensated probes on the analog discovery, didn't look like that on the scope.
But thinking about it, likely your right. It would be more sensible to read on the falling edge. I'll work on that assumption I think.
Don't forget to try Michael's suggestion of programming with some predefined 'visible' data, like A5 or DEADBEEF so that you can ultimately see the data patterns.
Keep it up David. Nothing rewarding ever comes easy. I like how you take us on the journey. Very down to earth.
In my opinion the best video of Dave2 so far :)
Surprisingly watchable for a Dave2 video.
@@ElectraFlarefire No one is born a master.
D1 was better than D2, (the absolute classic it is.) but D2 still was pretty excellent.. but definitely have to say D3 was hopeless then I stopped watching the series.
This was really interesting. Looking forward to future videos about this.
Maybe lower supply voltage for read cycles? Also have you generated a hex file to write 0x00-0xFF to see where the pattern shows up in the stream?
Very interesting, looking forward to the next installment! Cheers
Thanks!
I really enjoy videos like this. Keep em coming. Love to see what you figure out.
Instead of using this toy scope (only 8 ksample memory, seriously?) I would recommend to use one of Dave's good scopes, with megabytes of sampling memory, and 4 channels input. Would make reverse engineering much easier. The Keysight scopes have even the nice segmented memory feature, which allows you to sample multiple blocks with long pauses between, but still at high resolution for each block. You could probably record one full programming cycle with it.
The protocol for clock and data looks like SPI. With a Keysight scope you can also enable SPI decoding for selected channels, so that you don't have to manually decode the 0's and 1's, and then you can compare the numbers with the programming file to see where the actual programming starts. You could even read the scope memory over ethernet with SCPI commands to analyze the data further with e.g. Python script.
We are moving the lab, they are in boxes :(
It does look like SPI, there is some variations though, I suspected the same thing. Word size is all over the place if it is SPI. The scopes as far as I know only allow for a single word size? I also ran it through a script to decode it, that actually works and is repeatable, but not in this part of the video maybe in the next video :)
@@davidledger5941 At least with my relatively cheap DSO-X 3012A you have to specify the word size for the SPI decoder for the whole waveform. I think the easiest would be to get all the data of all changing pins of a full programming cycle on a PC, and then analyze it offline. You could even publish the sample file, together with the IDE project which produced it, and then let some geeks work out the protocol :-)
Might be fun to build something with a Beagle Bone to capture the data. There was a Hackaday article about the BeagleLogic, a 100 MHz / 14 channel logic analyzer. Right, there are different voltage levels, but looks like only a few discrete levels. You could easily build a simple encoder with a few fast window discriminators and some fast logic (CPLD) to encode e.g. 8 different voltage levels in 3 bits, which would give you 4 such analog channels. And you can record 340 MB continuously with the BeagleLogic.
But maybe easier to wait until all the big scopes are unpacked and then just get the data from them. But I don't know if they allow to read the full sample memory over SCPI, would be interesting to try.
I was about to write almost the same thing. ;-) This seems like it could be emulated using SPI and MOSFETS for level shifting. It has all the same features of SPI at multiple voltage levels. Start differentiating between voltage levels using a pair of level shifters, then decode using some kind of SPI protocol decoder. If SPI doesn't work, you can write a custom one using the Saleae logic analyzer API or post process in Python. Then when you have aggregated data, start the actual reverse engineering in software. This will likely yield the best results fastest.
Good thing about doing it a bit bootstrappy (if that makes sense) is that suddenly, the techniques used suddenly look a whole lot less out of reach to those of us who might not necessarily have access to beefier gear. I mean, call the analog discovery (and digital discovery for that matter) a toy scope if you want - and I won't necessarily disagree - but they're more or less the sweet spot for starting out without breaking the bank too much. Also, lots of instructional material available and really quite versatile, not to mention often available either for educational prices or even just for use in a simple school/college lab without too much of a fuss.
I have seen programming patterns similar before. The programmer was sending data 'records' which contained various bits of information such as where the data was to be saved. This was then checked by the device using some sort of checksum. The programming voltage was then raised to allow the data record to be saved to the devices flash memory. It was similar to the way that a PIC self programs. Possibly the output pulses are some form of handshaking. It would be interesting to see what relation they have to the clock and data.
very interesting!..crazy it has so many voltage levels.. i like your vids David..straight to the point and no BS!
yeah, no 5 minute outtro waffle either.
Old school EPROMS used to do that. You'd have a supply at 5V for read and 12V or 21V for programming.
electronicsforu.com/electronics-projects/manual-eprom-programmer
Nice to see you are losing your nervousness and presenting yourself really well
I'm getting a very Bletchley Park vibe with this. Love it.
I like that new end-screen!
I like it. I was pondering making a programmer for those micros. And you have provided a starting point. I don't have a programmer to compare, so if I get any ideas, I may ask you to look at it again.
Dito. These seem like great little micros, but to really put them into the super useful category you need to be able to up scale programmer throughput while maintaining the ability to change firmware faster than out of house services would allow.
great Video. I'm thrilled looking forward to further more Videos with David....
In order not to lose the low voltage part in a logic analyzer capture, feed in the signal not through a resistive divider, but through a series resistor and a zener to ground after it. This will "cap" the high voltage signal down to the appropriate level while leaving the low voltage one unaffected (if capacitance of the zener screws up the rise and fall times, you can probably add a tiny capacitor in parallel with resistor to compensate).
The high supply voltage could be applied during the writing sessions in order to provide enough power to burn the fuses in the one-time-programmable memory.
Also, I think some Atmel MCUs have an alternative parallel programming mode that utilizes high programming voltage (you are supposed to use it if you've accidentally disabled RESET pin by setting fuse bits incorrectly). I'm not really into Atmel MCUs, so can't tell more specifically...
P.S. Did you notice there's exactly 8 bytes sent between each "chip select" line release?
Good idea!, zener divider seems the most simple solution so far :)
Or instead zener, you could use green/blue LED. AFAIK LED has little parasitic capacitance.
David Ledger i was thinking ac coupling, but that wouldnt do much for the large “swing” , a zener is a better idea
What is wrong with using an BJT inverter tuned to switch at the lowest threshold?
Nice, informative video. I'm looking forward to the rest of the reverse engineering.
I watched the commercial at the end, instead of skipping it or clicking away. Support!
Thanks David, I did find this interesting. I look forward to the next part.
Use a beaglebone +beaglelogic. Will give you 100MHz logic analyzer up to 320MB samples. Also you can use an analog comparator from the supply voltage pin, so the threshold could follow the varying supply.
Interesting. I have a beaglebone lying around doing nothing...
Can the high voltage switches be for the actual burning of the data like how old micros required 12V on a pin to program?
If the slower clock pulses are not just providing the main clock for the chip to program itself, could they be polling to check for operation complete?
Also how did you check direction on the pins? is the programmer or chip driving the line?
I am on edge of the seat about this series...
Could it be that each voltage level could represent, Input to buffer, Shift to memory location, burn fuse, verify data.
I thought something similar - the different voltages invoke different sets of commands - would seem sensible given the dearth of pins.
@@mahlapropyzm9180, would seem to be the only reason to change the state of the power pin. CS pin could just handle the 9 volts. Kill 2 birds with one stone.
Good idea!
Great content!
Great video! Hope to see David do more videos.
Is there a way you could share the recordings from your analog discovery of the programmer so we can also have a look at it?
Hay, Young Dave - good to see ya, bud !
Also I am wondering if variations in overall timing are just due to the steps being sequenced by some software on your PC, which is at the mercy of the OS scheduler.
Could be partially, I did observe it on an oscilloscope, the saleae logic and the analog discovery.
Lol thank you for reading my stream of consciousness brain dump
I think the software sends the entire ROM to program into the programmer, and then the programmer takes over. (Because: I think it can program with the button on the programmer when the PC is not connected?) There could still be weird delays that aren't part of the programming algorithm, maybe the MCU on the programmer has a scheduler.
I wonder if the programmer is bitbanging, not using dedicated hardware to drive the GPIOs. That may explain the variation in timings. Longer code paths take longer to change the programming lines. (Since its clocked, the baud rate doesn't really matter)
Interesting, thanks for sharing 😀👍
You could buffer the data line with an opamp, use a zener to limit the maximum voltage and put a comparator on the zener resistor to tell when the voltage is high. With multiple comparators you could even “digitize” the high voltage levels. It costs you some more pins, but at least you can use a normal logic analyzer
Instead of trying to turn the analog signal into a better digital signal, why not just probe the digital signal closer to the MCU, when it's still digital? ;-) There might even be debug/test ports/pins/etc on the programmer board.
I think it clocks out on the rising edge bc of the ringing on the data line every rising edge, (could be oscilloscope noise), and sampling on the falling edge
Low frequency clocking may just be that the programming is being bitbashed by a micro, and the timings are accidentally different in different parts of the process due to alignment of the stars when the programmer's firmware was compiled :) have you guys torn down the programmer?
This is what I was thinking too- perhaps the timing variations are more of a programmer quirk than a necessity
That could be why the timing is different. It still indicates that the programmer s doing something different during fast vs. slow cock pulses. Whatever is happening during the slow pulses may take more cycles for the programmer to process.
Curiously, what treatments are used. Is it an ARM company
Dave reviewed a zeroplus logic analyser, I did a review on the same one, I think you can get that to read the data as you can set the thresholds you want, and read all the pins at once. That thing you are using doesn’t have the resolution you need, plus the zero plus can do decoding at the same time, to help with deciphering the data.
Maybe you could try upload the programming sequence as a file, and see what people can do?
Q&A please
can someone help
i have large strong magnet - is it ok to use it to hold lithium l.e.d torch with it, dose it harm the battery? i mean this this hold 20kg easily
Useful video 👍
Doesn't Dave have a saleae logic analyzer?
If it is a Logic Pro it would be capable of analog sampling 5 channels at 50 MS/s, with an Input Voltage Range of -10 V to 10 V.
Original model only.
How about starting with just the verification process as it might reduce the voltage shifting. Once you understand the readback it might be easier to spot the verification which happens during programming, I'm wondering if it's verifying block by block rather then doing it at the end.
As others have mentioned add some patterns into the program which you can search for and please switch to using a logic analyser either clampling the voltage or with a line buffer. Speaking of which it would be useful to determine which lines are input, output or tristate during programming.
Could the protocol be JTAG-like, with data shifted through a weird length shift register then pulsed in/out of circuits? This could explain unused pins getting pulsed each sequence cycle as synchronization bits shift past them.
Of cause full JTAG uses 3 data pins with approximately equal activity on the two busiest pins, so can't be that.
Where can I buy the programmer?
Not a clue what the hell you were on about but still found it very interesting. Looking forward to when you crack this sucker!
Programming these things post assembly would be super handy.
Just put a good logic analyzer on every pin for an unprogrammed chip and hit it with unique programming code and observe what happens.
Actually did that, it is interesting but very unclear where the data starts and stops, I think there must be some information at the start and end that changes which depends on the data but is not part of the data.
@@davidledger5941 kind of sounds like a checksum (+ header); these segments are constant for a constant program?
@@Wren6991 Yes they are constant, it does seem like a checksum, but I don't know where the data starts yet so cannot confirm.
Then I'm looking forward to the rest of the series :)
@@davidledger5941 can't you subvert the programming with custom data? Unique data from start to finish so you can differentiate it from the rest of the noise? Just have it write PI or something so you can see the data and what parts are being written and when.
This product SC91F711 I did not find his programmed (what the name of the programming device)
Great job, keep up the good work, this is really interesting. Also, did you already take a look at the PDK files that the IDE outputs? I noticed they're definitely encrypted or encoded in some proprietary way, since by just changing a value in the program (i.e. take a program that initializes a variable and loops forever, and change the initialized value from 0x01 to 0x02) a whole lot of bytes change, I tried with more than 20 different programs and it's always the same 2k region of the binary file that changes (I mean, it is totally different, not a single byte equal). That file format will be an interesting thing to RE.
Have a look at the EEVblog thread, they're doing some weak XOR "crypto" which is reversable.www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg1942411/#msg1942411
@@goosenp Many thanks! Really interesting, I didn't notice it. I'll start looking at it now that I have some kind of starting point. The guy did a really good job at RE the IDE.exe, as soon as I opened it in IDA I got quite a bit scared by the amount of stuff inside, given I'm not a RE guy by any means.
Good work there - and a nice presentation!
To me it seems unlikely that the micro can keep any kind of state when the supply voltage is turned completely off - could it be that some of the other pins is used to provide power? In the case of the PICs or even old EPROMs Vpp is supplied on a different pin than Vcc.
You could also use a level shifter connected to the varying supply voltage to translate the ones and zeros for your logic analyzer.
The development OTP PIC chips I was working with had a window in the top and could be UV erased. I believe someone else commented that you could achieve the same effect by decapping a regular one. Not sure if that would work with these.
I can verify the EPROM PIC1657 devices used the same die as the OTP HS part. Source: Microchip Technology, San Jose, California 1993.
@@Peter_S_ And if I'm not wrong, the 12V is a eeprom programming voltage.
@@chaos.corner No question 12V operation of a 3V3 part is all about delivering Vpp to OTP cells. It's 1985 all over again. ;-)
Good Video!
I like when you discribe small details, what active low means for example. or that the pin setting it for programming are normal GPIOs, good stuff for beginners.
Love the end card
Has anyone mentioned David's T-shirt? Love it!
The LF may be for charge transfer: Clock in the data, then repeatedly bang it onto the storage wells. This was done using the data lines in parallel EPROMs and OTP-ROMs.
I agree with the call back to PROM programmers back in the before times.
I suspect when you find out what it is, it will probably be pretty simple.
Is it a AVR programmer protocol?
Where can I buy the shirt you're wearing?
You seemed to be guessing which signals were on which pins?
Surely the datasheet shows the names of the programming pins?
Use a voltage level shifter to buffer the signals to your logic analyzer, plus a bank of comparators to signal for each of the different voltage levels
Would a level shifter be of any use in these situations with the different levels?? Maybe a level shifter in conjunction with the analyser would help?? You could use the resistor divider to probe the level shift, and then another line to probe the data at the shifted level?? Could it be that they are using some sort of multi-level encoding to shift more than one bit at once? (A bit like how MLC and TLC SSDs store data??) Just thought i'd throw a couple of ideas out there. Interesting video. :)
Use a logic analyser and feed the pins into two channels. One a direct Zener limited link and the other a divided version of that where you can set the threshold to only trigger a high on high voltage pulses. That way you can read both the high and low voltage states safely.
TVS to clamp so that you can read it?
Any schematic etc ?
Can you place some resistors within the data lines to tell which lines go out and which ones go in? The weird timings can be a result of poor RC clocks that comes from inside the chip, used to time the writing of the memory. Memories can be relatively slow to write into, so the chip might be advising the programmer on a good timing for that (which could also be variable!).
The pins are pretty low draw, I think I'd need a unidirectional buffer to determine the direction.
David: To take various pins out of the equation of "which are actually used to program".... maybe try snipping the legs of the chip and see if it programs? Example: on a fresh chip, snip pin 2, attempt programming. New chip: snip pin 3, attempt programming. And so on. Then you'd know for sure which pins you'd need to probe. :-D
@@linagee It seems to disallow many things and it seems to check for the presence of all pins before allowing programming. It won't program if I stuff up a connection for example (which i frequently did on many pins).
@@davidledger5941 Perhaps a 1K series resistor plus a 100K pulldown on each side? That should produce some drop that you could measure.
Hi Dave, use Saleae analyzer for decoding data. Put a comparator on the supply voltage and connect the output of the comparator to one of Saleae inputs, so you can see high/low voltage periods. Flash it with some known data and here you go.
If the logic levels are going up and down with the supply voltage, could you use one of those level shifter chips which have two supply voltages, one for the input (which would be the varying programmer VCC, the other the fixed output voltage for the logic analyser). Or maybe just use multiple taps on the voltage dividers to drive several digital inputs of a logic analyser for each pin, and merge the data once sampled. Certainly an unusual set of signals.
14:20 cant you just use a zener diode with a resistor?
I wonder if Mike used the big blue programmer ..
If you want to put these signals in the range of a logic analyzer, use a series resistor into a diode clamp rather than a divider. This circuit will be transparent to the lower voltages, and keep the higher voltages within the acceptable range of the logic analyzer.
Maybe you can adjust the voltage levels with something else than just a voltage divider to give all pulses the same amplitude for use with a logic analyser.
Looks like the data transitions on rising edge and is captured on falling edge. I'm sure you could dump the bits out with a python script, and search the raw bits for chunks of your program binary :)
I do have a script to dump out the bits :)
What i haven't seen yet is data change that proceeds a clock pulse, this made me think that the micro wasn't returning anything at all.
I just haven't done a video yet :)
@@davidledger5941 what does the programmer do if there's no chip attached? :D
@@Wren6991 It gets angry at me lol just beeps.
It also gets angry when any pin is driven and a few other things seems to cause the same thing.
The power off/reset phases in the overall process might not involve state in the chip other than actually resetting all state by power cycling. Possible phases could be:
Initial quick probing to confirm device inserted properly (right way up etc.) and the supply levels for the next phase.
Small sequence to read out chip id (model and design revision), selecting different procedures depending on known chip features and bugs.
Longer test sequence to run all chip parts through test patterns and reject bad chips (this would be the long sequence at normal power).
Actual programming of main PROM.
Read back of entire PROM to verify all bits correct.
Additional passes of write/verify in case the fuse design needs to be "burned" multiple times to stick.
Final burning of the anti-readback fuse and checking that it can't be read anymore.
I never thought about what this means before, but these comments got me thinking. When you "burn fuses" is that literally overheating a connection in the chip to the point that it disconnects?
My gut says that the CS line is the direction and that the programming is done in blocks. And after each block a checksum is sent back.
Sample rate does not suck (at least it shouldn't matter for such slow chip), sampling memory does. Why you didn't just use one of dozen of 4ch scopes from the start ?
I'd start looking at the file format of the programming file and figure out how to put arbitrary binary data into there. Then you can place a repeating pattern into it and give yourself something of known value to look for.
Use more than one logic analyser channel per signal, just with another voltage dividers
Might just try using a shunt resistor on each line with diodes tied to a power supply 0.7V - 1.0V less than maximum logic analyzer tolerance.
Do a full recording of each line at a time, and post a graphic somewhere so we can all do our investigating .
Awesome !,!
You da man, man
@David Ledger Great Vid, reverse engineering always starts out looking horrifically complicated. Not sure if you have checked this yet or not, but I imagine you are programming the same chip over and over? If so have you checked to see if there are any differences between a blank run and a programmed re-run. In case it changes to a verify only mode (or at least to something different on already programmed chips)
I could be wrong but I think I saw some information for programming in circuit in one of the previous videos. This should help in knowing which pins are actually used. The different voltages could be down to writing at a high voltage and then verifying at a lower voltage. Finally some of the DATA may actually be just noise/pick up. Add some strings to your code with some recognisable patterns. Finally capture a whole programming cycle from start to finish in a digital format that others can see and crowd source the cracking ;)
Did you pursue that?
I agree that you need better equipment. Wonderful video, keep it up!
The chip might require the higher voltage for the writing process.
use resistor and zener diode
From the PDK5S-P-003 manual, selecting 'on board voltage limitation' may help by preventing levels above 5v. You should try to find two identical sets of data in a capture, one of them being programming, the other the verification. Align the two and then look for a pattern, this should allow you to work out the number of bits in the sequence - it may possibly be more than 8. Also the manual has a diagram for in circuit programming requiring only 5 pins, so you only need to really monitor clock, data and reset, the purpose of variation in vdd level can be worked out later
Perhaps, the VDD level might determine the state the chip is in. More experimentation is needed.
@@davidledger5941 Maybe, but do read the programmer manual 'on board voltage limitation' - 5.1v zener to Vdd. Sounds like it's purpose is for in circuit programming when the circuit has a 5.1v zener limiting the voltage to the micro when powered from more than 5v. Measure just the three clock, data and reset pins - resistive divider >10k ohms to the programmer (again according to it's manual - it's on page 26)
@@davidledger5941 I have had a quick look at the PIC programming spec and also the AVR programming spec. The PMS150 looks to be closer to a PIC in the way it's programmed. The AVR programming requires a clock and two separate data lines (MISO & MOSI), where the PIC only has clock and data (bi-directional) so the PMS150 looks closer to that style or programming method (only a clock, single data line and reset used).
1 cent more?! rip-off.
Wouldn't it be funny if it was the same chip with just different fuses set? (Maybe even just by the programmer?) Would they really have an entirely different chip die? :-D
@@linagee If the fuses were set by the programmer, how should it know then what type of mcu is to be programmed? There must be already some fuses burned before. Or otherwise, it should be possible to buy cheaper units and to just tell the programmer you are using an other model. But I can just hardly imagine they are using a common die for many models since that selective enabling/disabling function and the (in case of cheaper models) never used circuits would be a waste of space for the manufacturer. They are making millions of every model on its own already, a flexible design would be pretty useless. It only is practicable if the die area per unit is as massive as a cpu where the additional circuit just adds less then a percent of overhead.
But regarding preburnt fuses, I got an idea for some applications: With a common die, it could be possible to mark chips in the bonding stage. Gold wire bonds could act as "jumpers" to tell the die in which kind of ic it will live. This way, the die could have more pin connection areas than the actual packet at the end. I recon they possibly do that already with identical models for different packages. (Like 8pin and 16pin ATmegas)
Use a 3 dollar saleale clone, but with a pull up and a diode to the interface to pull it to ground instead of a voltage divider.
Stupid thought, why not set up a series of ADCs, one for each pin, tolerant to the maximum voltage, and just use the logic analyzer to capture the ADC output? That could the be dumped and reconstructed into a waveform. It’s not like there’s a ton of data there, nor is it all that fast.
This would essentially emulate a large buffer low res low bandwidth 8 channel DSO (you might have one already), and you could capture the entire programming session.
Tearing down the programmer and reverse engineering the physical circuitry might provide more clues in terms of the different voltages.
Anyone have a site for a used or discounted ociliscope
ebay
Dave made a tutorial on how to look for one on ebay. Search the eevblog channel
Ask some professor at your local trades highschool, particulary one that has electronics as one of its options (duh!) or maybe ask in some electronics shop, some times the clerks are there because they like electronics so they might know of some place.
Dave said used analog scopes are cheap, but that depends on the country and what is cheap in some places might not be in some other.
Otherwise you can make a "soundcard" osciloscope, and even make one with a couple of arduinos and a bit of coding. But i'd recomend using several ATtiny's instead to make the high speed ADC and then yeah maybe and arduino to get the data out fast enough (you might need to compress it a bit or make a parallel port interface.
With each ATTiny you get like 15ksps at 10bits or more if you go 8. If you are doing low voltage you could even do 8bits and maybe get like 25-50ksps and with 4 of them that'd be 100-200ksps which is quite a lot more than what your sound card can do plus you get an actua frontend (provided you make it) and dont need to relay on the sound card for accuracy.
If you are willing to spend the time there are definetely ways to get your way there or at least get cheaper alternatives that can cover 99% of your needs.
Not sure if there's oepn source proyects already you can adapt, but otherwise making the gui in python isnt that hard.
Reverse Engineering made simple by little Dave
At 8:18 it's clocking on the falling edge.
Would it be worth it?
Dunno. Maybe?
@@davidledger5941 Maybe, sure it would be fun
There's probably internal logic, on a few different pins which require a succession of rise and falls to avoid internal congestion. There could be different levels of internal logic which require the offset to transport the data on the rise and falls. It's like the 1,2,3.... logic, each has to have room, internally to electronically perform the next step, otherwise an error correction scheme will reset the operation because 1 or 2 or 3 happened out of sequence. My best educated guess tells me that you have to provide a sequential pathway, and that it's not a completely integrated circuit and you have to understand its operation a little more. Personal guess and prove me wrong fan boys of this ic . Edit; "it takes two to tango" logic. And require an offset in rises and falls. From external losses. That's my 2nd guess. They expected a rebuttal which requires external time delay to complete the logical loop, or reset.
14:58 What?
It's an ARM based programmer, right? Why not dump the firmware and slap it into IDA Pro? :-)
Also to your "I can't use a logic analyzer because of different voltages".... then probe earlier into the path, maybe right off the ARM or before a buffer chip raising/dropping the voltage?
It's possible all the different voltages are just a trap/fake. Maybe put all the voltages it's applying through a bunch of transistors that just switch on/off and see if it still programs fine? (Oh wait, bidirectional would be needed... so... something more complicated?)
yeah but that implies soldering tiny wires which is a pain and even then maybe there are and gates somewhere to change the pins voltage or something.
Yes its a STM32F072 I believe. Its the same IC as for the uSupply so I'm pretty familiar with it :).
Its a nice IC, but it is a little memory constrained...
You could try programming without each of the presumed extra pins one at a time to see if the signal is from the chip/programmer or even relevant to the process.
I'd be more interested in something that is not OTP, or if you approach this subject with a top down abstraction of how to do this kind of thing in general.
For instance I have an interest in ABOV's offshore 8051's but I'm not paying for Keil/Segger JLink just to check them out. I have absolutely no interest in taking the time to learn on an overpriced toolchain or 2k limited demo and I'm not going to get familiar with an overpriced tool that makes any future chance of commercial development impossible with insane licensing fees. Those factors are what's holding back my curiosity on stuff like this. Sure I could pay the ~$100 for a Jlink and learn most of what I need to know on Keil, but IMO the hardware potential doesn't outweigh the limitations. How do I get something like this going with SDCC without the proprietary handicapping junk?
At least that's why I'm curious about this stuff. Reversing the OPT chip isn't really very useful IMO. "How do I get a random poorly documented IC" programmed is more my curiosity.
An easier target would probably be something like the old Lattice PLD's like a GAL16v8. Those are dirt cheap, the documentation is rare but available, and they would be much much more useful to the Maker community if someone showed how to program them clearly. This is especially true if you can pull it off without Windows. I've heard people complain about wincupl, and that the TL866 programmer sucks at PLD's. Another CC I was talking to yesterday said he's using dos to program them now. That's the kinda thing that reverse engineering a programmer and modern working toolchain would really help IMO.
BTW Dave-ii, I like that you didn't use the big tools. The Beagle logic idea others posted sounds interesting, and the analog Discovery is doable, but big Dave's toys are way way way out of my budget. I'm still playing with the periscope-screened DS1052E like the one Dave hacked way back in the babeevblog days. If I can't do it with that, it ain't gonna happen.
Thanks for the upload, and GL!
-Jake
yeah, I hope that someone will try to reverse engineer the protocol. I've seen a lot of project about GAL/PAL programmer but no documentation on programming protocol
@@ThinhNguyen-tf6sx
I was talking to Doug over on Retro-Depot about it as he's made a few uploads. He was the one saying he's trying to use DOS now. I think Robert Baruch has some stuff on the subject too, or maybe it was on his website, I forget. Doug has an interesting Z80 project that uses several GALs.
I would certainly use PLDs more if it was easier. I like the little EPM240 CPLD dev board I've got, but I don't like 100 pin SMD packages on boards I'm etching myself so I don't play with this stuff as much as I would like.
I suspect it will be using an algorithm similar to this patent description to program the PROM cells. It certainly explains the strange assortment of voltages and timing you're seeing.
patents.google.com/patent/CN106340323A/en