So, while satisfying my TEA while browsing ebay (the equivalent of hungry grocery shopping), I came across an as-it Siglent SDG1020 board that was too good to pass. The description was "Original Siglent, working hardware but requires the installation of the Firmware, without which it can not work." [sic!], but fair enough, it was sold as "for spare parts" so I did not expect a working board. (And besides it was cheap enough that I didn't care much). Per the seller, the board - when connected to a display - would be stuck at the boot screen. My plan was to somehow fix the board, put on a custom PSU, and then use the unit via USB remotely.
The board arrived, and after reading the SDG1000 service manual (
https://www.siglentamerica.com/USA_website_2014/Documents/service_manual/SDG1000_ServiceManual_SM02010-E01B.pdf) I could reverse the power supply requirements (20V+/-, 6.8V+/-). All on-board voltages are okay. I hear the relais clicking a few times, and consumption is okay-ish (700mA..1.2A on +6.8V, ~200mA on -6.8V, ~20mA on +/-20V).
Per thermal cam a few parts get hot, but - with the exception of the USB interface chip - perhaps not unusual (mostly DACs, but all <60°C). I can see the two DACs data being driven and outputting a slow sine wave, and I can see the display output driven as well.
But the USB chip - an ISP1763A - gets freaking hot. Input voltage (3.3V) is okay, internal regulator (to 1.2V) works as well. No (significant) output on D+/D-, even when connecting a device / host (it has two ports).
Measuring /CE line of the ISP1763A yields my first suspicion: after no accesses during boot, at some point there are infinite bus accesses to the chip. It seems the CPU is trying to read from the USB interface chip, but somehow not getting the right response. Measuring data lines confirms - the ISP1763A does not drive the data lines. :/ I scope the address to be "0x20", the data port.
In a side quest, I enable the use of a Lauterbach debugger (that I once got in an auction for free - long but awesome story for another day), so I can attach to the Blackfin CPU. And voila - the CPU is hanging in a tight loop trying to read from 0x20300020; 0x20000000 is the external bus, and 0x20300000 apparently decoded to the USB chip, and 0x20 is the register offset (which I previously confirmed by scoping address pins).
I dumped the memory, and obtained the current framebuffer output - the SDG1000 splash screen; this correlates with the screen shown in the ebay auction.
I disassembled enough code to find the "USB initialization" routine, and when I set a breakpoint early in boot, I can skip it. The device then continues to boot, and capturing the display data again shows that I'm in the main menu, and could edit the waveform now (or enable outputs) - if only I had keys!
While I haven't proven that the analog part is not broken, the broken ISP1763A is definitely a show stopper. Unfortunately the part seems very hard to get.
I tried using the UART on the device - my remote hope was that I could just supply SCPI commands - but unfortunately there doesn't seem to be any UART access code in the whole firmware…
I tried to clean/resolder the pins of the ISP1763A, but of course that didn't help. I measured all pins and couldn't figure out anything else to be wrong, so I assume the chip is just busted.
I'd be happy to hear any smart ideas of how I could fix this. I thought about hacking the application to read SCPI commands from serial port, but a.) meh it's a blackfin and b.) having USB would be cool.
Home
Help
Search
Login
Register
