Instek! I want my money back!

Futile, of course. I bought this GDS-2062 some time ago, but wasn't ready to really use it in anger until recently. And I have been angry. The Java-based scope utility is working well, but I've reached the end of the road with this oscilloscope, I think. The utility tells me that when the Silicon Labs IDE does an 'Erase code space', the C2 commands are WA02WD02WD04WD01 (after reset) - a write to the FPCTL (Flash Programming Control register). The next command follows around 20ms later, and is WA00RD11WA01RD01. That's reading the device ID and revision from the target. I may have got lucky in capturing the second burst, I didn't have any trouble until I started trying to capture the third burst. What I did was to use the scope to look at the first 200ms of traffic from the IDE. There's a lot missing, but you can tell there are bursts of commands going on for some time.

I assumed the bursts would be reliably spaced, so I used the scope to look through the traffic 5ms at a time, by repeatedly advancing the time delay and erasing the device again. The third burst contains a lot more commands than either of the first two. Its start is not reliable though. To read the C2 commands, the scope has to be set to 10us (microseconds) per division, giving 200us worth of samples in the window The third burst was not in the sample window the first time I looked for it, so I set the scope for 250us per division to try to see what had happened to it. On two successive erase operations, the third burst occurred at before 25ms and after 26ms into the erase operation. Given that I need to capture that burst in a 200us window, hope is starting to recede...

The GDS-2062 has a delayed trigger facility, where you can use the external trigger to delay the normal trigger by a fixed time, or number of events. Fantastic! Either facility would do! I could just delay the trigger by 24ms after the reset, and then the next rising edge on C2K would be the start of that burst. Delaying by time would obviously be of less and less use the further I got into the traffic, but I suspect (and hope!) all I want to know is at the start of the traffic. So, run a wire between the C2K line and the EXT TRIG connector (I don't have 3 scope leads)... select the delayed trigger. By time... it only goes up to 1.3ms! Useless! Hey, well, given the moving timing problem, the event-based delay might be better anyway. Just have to count the C2K strobes. Don't hold your breath. The delayed trigger doesn't seem to honour the 'Single shot' setting from the normal trigger. Yes, it triggers after the selected number of events, perfectly. Then it fires again, after that many more events occur. And again, and again... I think you get the picture. It doesn't work.

I'm going to drink some coffee now. I feel better after getting that off my chest. I might go back to my micro-based C2 program and see if those codes written to FPCTL really are the key. Alternatively, I might go back to my micro-based C2 snooping program and see if there's anything I can do to speed it up. I'm not really hopeful in that regard. The strobes arrive at 500ns intervals and last less than 100 nanoseconds. The micro has a 25MHz clock, and can execute some instructions in 1 clock cycle. The instruction to loop around checking a port bit executes in 3 or 5 cycles, so can't capture strobes reliably (3 cycles is 120ns). Using an interrupt is out - the ISR calling mechanism itself would use all the clock cycles available between clock strobes!

The only other alternative is to make some hardware to do the C2 snooping. Or buy a better oscilloscope. I think by now I've easily lost in time what those good, but so much more expensive scopes would have cost me. Coffee calls.