Silicon Labs F530 and C2 Flash Programming AN127

This should be the last word on this. The VDDMON change posted earlier is the one change that must be made to the code in AN127. The FPI initialisation sequence is possibly a red herring. I tried the sequence of 0x02, 0x01 from AN127, and it works just fine. Intrigued as to why two different sequences appear to work, I tried 0x02 on its own (doesn't work) and 0x01 (appears to work). The tests were separated by warm resets (RST line low), so there's possibly some chance the initialisation was surviving the reset, but now that this hurdle to progress has gone, I've lost all interest!

At last! C2 Flash Programming the C8051F530TB

I spent a great part of the afternoon ploughing through the C2 commands being sent from Silabs' IDE, trying to find the clues I needed to get my embedded C2 programmer to work. I could see the packets of data becoming more dense after 100ms or so, but it was taking me more than an hour to analyse 10ms of data. I was just about there - though that doesn't mean much. As I noted earlier, there wasn't anything in the C2 traffic that actually looked like a device erase. Once I found a device erase command, I'd have to work back through the C2 commands to find out which one or combination actually accomplished the erase.

ec2drv now supports F530

Ricky was in touch about the ec2drv software, he'd looked through the debugging logs I'd sent him and spotted the messages that made writes and erases work. He mentioned the VDDMON register, as had one of the posters at the Silicon Labs forum I posted to, but included the register address (0xff) in his remark. That explains the WAffWD and WAffRD messages in the previous posts! After a quick read of the datasheet, it seems it's necessary to prepare the VDD monitor, allow it to settle (there's a flag to check), and then set it to a high level before flash programming or erasing. Once I'd added that to the code I'd written, it worked first time! Ec2drv seems to fully support the F530 now, so I'll be glad to get back to Linux for developing on the F530. All I needed was some way of writing my code to the Silicon Labs boards, and the only way (up until today) was by using their IDE on Windows.

If you're hung up on your implementation of Silicon Labs' AN127, and you're using F530 or F520 parts, all you need to do is to change the FPI initialisation to 0x02, 0x04, 0x01 (AN127 says 0x02, 0x01). And add the VDDMON setup code to your FPI initialisation. Happy flashing!

Tired. Deja bu and the Malaysian bathroom.

Tired today. My 16-month old daughter was struggling with her milk last night. Then she rolled off the edge of the sofa and banged her head on the floor. Floors are almost always tiled here, so it's a hard landing. She seemed a bit inconsolable, then the note of the cries plunged like something from the Exorcist, and I was wearing her last 3 meals all over my neck and back.

One advantage of living in the tropics is the bathrooms are 'hose-down'. We had a varnished pine floor in our house in the UK, with painted walls. We always worried about splashing water out of the bath. Here, there are no bathtubs, just what is locally called a 'water heater' on the wall. It's optional: when you buy a house, chances are there's a shower head attached directly to the water feed for the bathroom. The water heaters are an added luxury, but not really necessary. The bathroom temperature must be at least 30C, and I suspect the 'cold' water is at least 20C. Since it comes from a tank in the attic, it may even be 30C. The 'bathrooms' are just tiled rooms, wall and floor, and invariably have a short hose on the wall near the toilet. Perhaps I'll write a full article about that hose sometime.

The short hose is handy when you're a vomit-covered parent and child, you just go into the bathroom and spray both of you off. There's a drain in the floor, in one corner. The drain in the downstairs bathroom hasn't been draining at all well recently, and when the washing machine (which is just outside the bathroom) and the shower are in use together, the drain briefly overflows. Last night, just as I was feeling lucky I had a hose-down bathroom, the drain stopped making noise, and bits of undigested baby food started popping up through the holes in the cover. A chill ran down my back, just writing that sentence. My wife took our very subdued daughter away to complete her cleanup and change her into fresh pyjamas. I sploshed around in the dilute vomit and wondered what to do next.

We'd bought a plunger when the drain first showed signs of blocking, and it did seem to marginally improve things. I used it last night, and as the hours went by, the water on the floor became clearer and clearer, and then actually dropped below the level of the cover. By that time, I had got over my revulsion at the soup I was standing in, so I conducted a 'manual investigation' of the drain. It's a big pipe, so a hand goes in easily. Just below the drain cover, I could feel bare concrete - the down pipe mustn't have come up far enough when they laid the floor, so I'm guessing they just stuffed a bag in the top and laid concrete up to that, before sticking the cover over the bare concrete. about 6 or 7cm down, I could feel the sides of a plastic pipe descending. At about 15cm, I could feel a smaller pipe entering from the direction of the handbasin - I recall the builders used the same pipe for the washing machine waste.

At about 30cm down (almost elbow depth), another small pipe could be felt, this time on the side of the pipe facing the back door. This ought to be the exit, but the pipe comes into the larger downpipe by more than a centimetre. Feeling around this pipe, it's obvious that there's no joint there. There's a jagged hole in the larger pipe with bits of soft concrete protruding through the gaps around the smaller pipe, and in places gaps that I could push my finger into, with something soft inside. I couldn't decide whether this pipe entered or left the larger pipe, so I felt further down. Just as my elbow went under the surface (face uncomfortably close to the bobbing carrot and milk curds), I could feel a pile of rubble. I fished out a few 8cm diameter lumps of the concrete they used as a substrate for tiling, and felt again.

The larger pipe's walls were smooth down to about 40cm below floor level. At the bottom of the pipe is soft, like very wet mud. At the edges of the soft bottom, I could feel the end of the large pipe. WTF? There's no end to this pipe, other than the dirt the house is built on. Capping the lower small pipe with the palm of my hand, I could feel a very soft suction - that pipe is the exit for the drain water. I'm guessing some drain water must just sink in the mud at the bottom of the pipe. I tried pushing a hose into the exit pipe and running some water into it, but all that did was add black silt to the dilute vomit I was standing in. I cleaned up as best I could and went to bed.

This morning, the level of water in the drain had dropped far enough for me to see what I was feeling last night. The down pipe is actually two short lengths of larger pipe of slightly different diameter, one pushed into the other. I suspect the upper section was added by the tiler who tiled all the floors in our house. Why didn't he add a longer piece? The two smaller pipes enter the larger pipes through holes that look like they were cut with a craft knife; jagged, with great gaps all around the smaller pipes.

My wife says one of her brothers has some drain rods and maybe a power washer at his factory. In the UK, I'd be straight on the telephone to the Lone Drainer, but here, I think I'd rather do it myself. I've paid for some very disappointing work here. In preparation, I lifted the drain inspection hatch by the back door. I cannot adequately convey my feelings. The chamber beneath has smooth concrete walls, perhaps a metre deep. The chamber itself is about 30cm by 50cm. The walls appeared to be moving as I lifted the hatch, but when my eyes became accustomed to the gloom beneath my feet, I could see that I'd woken up several dozen cockroaches, from peanut size up to thumb sized. I was shuddering so much, I think I pulled a muscle in my neck.

I fetched the hose from the parking area outside, and washed off the walls of the inspection chamber. It's briefly satisfying to see all the cockroaches wash down into the sewer, but they start coming back within a second or two of turning the hose off. There are 3 large pipes emptying into the chamber. One is for the toilet in the downstairs bathroom, One must be for the bathroom upstairs, and the third has a slow trickle of water coming out of it. The slowly trickling pipe has silt in the bottom of the pipe where the other two do not. I'm guessing that pipe is the exit for the bathroom drain.

I'm really not looking forward to this job.

C8051F530 erase by IDE: part 2

The next C2 packet is at 37ms. I've got a sneaking suspicion the IDE does this erase 2 or 3 different ways. Using the scope to capture this packet takes 2 or 3 tries. When it's in the sample window, it's dead centre every time. It never appears off-centre, it just is there or it isn't. The packet is WAa0WD80. This C2 register is read at 32ms, and returns the value 0x80. I'm completely in the dark. Again.

There's another short packet at 39ms: WAffWDe0, a write of e0 to C2 register ff, no clue still.

There's a large packet at 42ms:

WAb4WD06RA00RA01WAb4RD0dWAb4WD00RA00WAb4WD00RA00
WAb4WD01RA00RA01WAb4RD0dRA01WAb4RDff

This sequence is in AN127 - it's a read flash block command (0x06). This one reads 1 byte from 0x0000. By this stage I've flashed this device over and over, so of course, the byte is 0xff.

The last few packets I caught were at 43ms: WAffWDc0 (a write of c0 to C2 register ff, similar to 39ms). Another short packet at 47ms: WAa0RD80, similar to packets at 32ms and 37ms. A packet at 49ms is WAa0WD90, perhaps a response to the previous packet?

I have another packet captured at 50ms that is identical to that captured at 42ms. My sampling window for these captures is only 0.5ms long, so I have no idea whether both packets exist in the same erase traffic.

The last packet I captured is at 53ms:

WAb4WD09RA10RA11WAb4RD0dWAb4WDefRA10WAb4WD01RA11RA11
WAb4RD4a

I've broken the lines this way to compare with the (known) packet at 42ms. This is a 'command 0x09' to the FPI. It seems to take a 2 byte argument (the top line). It then reads FPDAT, and gets 0x4a. The read flash block command would read FPDAT for the FPI command status at this point. AN127 has all commands that read the FPI status and don't get a 0x0d response, abort.

That's the last packet I captured. The one useful attack may be that read command at 42ms. If I can fill memory with something other than ff, and capture that packet again, I'll know whether the erase has happened before that packet (it reads ff) or it happens after (it reads the fill byte).

I used a 0x55 fill byte. It took me 5 tries, but the packet I have reads:

WAb4WD06RA00RA01WAb4RD0dWAb4WD00RA00WAb4WD00RA00
WAb4WD01RA00RA01WAb4RD0dRA01WAb4RD55

Oh noes! It has read 0x55 from 0x0000, so this is before the reset! Well, that's a bit disappointing. But then, there wasn't anything that really looked like any of the reset commands from AN127.

To bed I think, this problem is for another day.

C8051F530 erase device

Collected quite a few C2 packets today. About time I had a look through them and figured out what to do next. A quick recap: I've written some assembly routines on one Silabs processor to send C2 commands to another, using their application note AN127 as a guide. The code will read the target device, but not write to it, nor erase it. I've had no replies to emails to Silicon Labs about this issue, so I thought I'd check to see how their IDE erased the device. Uh oh, a thought just struck me... there's a lot of traffic between the IDE and the target during an erase, perhaps there's a simpler utility somewhere that would reduce the amount of traffic. I might have been too hasty... checking... uh oh, there is a "Flash Utility"... does it simplify things... hang on...

Flash utility: connect

First check with the Flash Utility is connect. Scope shows at least 50ms of traffic. A first packet, then a gap of 20ms, then more packets every 3ms or so. That gap is suspicious - the same thing occurs with device erase from the IDE, and according to AN127:

Before performing any FPI commands, the FPI
must be initialized with the following sequence:
1. Reset the target device.
2. Wait at least 2 μs.
3. Write the following key codes to FPCTL: 0x02,
0x01.
4. Wait at least 20 ms.

The oscilloscope trace is courtesy of my Java scope utility. The scope itself will only show about half the data that you can see in the image, but the utility displays the whole sample buffer. Quite nifty. The scope utility is running on the Linux desktop I'm using now. The Silicon Labs IDE is Windows only, so that's running on a laptop next to my screen. It's raised up on a crate so the screen is similar height to that on the desktop. I use the brilliant Synergy software from sourceforge.net so that I can use my desktop mouse and keyboard to control both machines. The Java utility controls the scope too, so I can set up the scope from my desktop screen, then mouse over (from my desktop screen to the laptop screen!) and use the IDE, same keyboard and mouse - marvellous!

Flash utility erase

So I'm wondering if the first packet isn't the flash programming key codes. Anyway, the connect from the utility doesn't seem to be any simpler than the connect from the IDE. Let me check the device erase... looks very similar to the IDE erase, at least for the first 50ms. There's the same several-second pause, then a dialog. I'm not convinced it's worth looking further. Just one more try - see how long the traffic goes on for. Looks like heavy traffic for about 450ms - I suspect this must be a verify. I'm not sure why the long pause. Looking at traffic up 4 seconds, the scope shows nothing - but I'm looking at 1s at a time, so my scope may be missing a very short packet.

Flash utility set memory

The memory fill utility looks curious. According to AN127, the target device's Flash Programming Interface (FPI) must first be reset (a C2CK low for >20us), then wait 2us, then writes key codes 0x02, 0c01 to FPCTL, then wait at least 20ms. The 20ms wait is plainly visible in the trace above, but does not occur at the start of the memory fill. Curioser and curioser. There seems to be about 400ms of memory fill traffic, but the obvious hole a 20ms wait would leave just isn't there.

The IDE's device erase traffic

I felt lucky today, so I captured a bit more of the device erase traffic. It became apparent to me after several captures that the traffic's timing was so unreliable, I couldn't be sure I was capturing all the packets, or even that I have the sequence right. There are some interesting ones though. The first thing that happens is that the IDE resets the target, writes 0x02, 0x04, 0x01 to the target, and then waits 20ms. This is just like the section in AN127 that describes initialising the FPI, but with different codes.

The second packet comes after the 20ms wait: WA00RD11 - haven't a clue. The third packet has a bit more to it. It's different to what I thought was the third packet before - perhaps I was counting from after the wait? Hmmm, must be more methodical! It's straightforward: WA00RD11WA01RD00 is fetching the device id (0x11) and revision (0x00). A big packet follows:

WAb4WD01RA00RA01WAb4RD0dRA01WAb4RD03
WAb4WD02RA00RA01WAb4RD0dRA01WAb4RD97

I don't understand what this packet is doing, as I posted earlier. A packet follows this one (I'm not giving packet numbers any more, I'm not convinced I've got this right!) WAffRDc0 - again, I don't know. That packet appears at either 27 or 28ms. Another short packet appears after this one, around 32ms, WAa0RD80 - another don't know, though they look like reads of C2 registers. Who knows what those registers are?

Two big packets follow, at 33ms:

WAb4WD09RA10RA11WAb4RD0dWAb4WDa7RA10WAb4WD01RA11RA11WAb4RD00

and at 35ms:

WAb4WD09RA10RA11WAb4RD0dWAb4WDefRA10WAb4WD01RA11RA11WAb4RD4a

The pattern of the two packets is familiar. In AN127, commands to the FPI via FPDAT (register b4) follow a similar routine. The WAb4WDxx is an FPI command. Poll for InBusy does a RA until the 1 (7-0) bit is reset, hence just one RA10. Before reading, a RA is used to poll OutReady, which checks the 0 bit is set, hence just one RA11. The FPI Command Status is checked next, that's the WAb4RD0d. 0d is good-to-go. Whatever command 09 is, it seems to take a 2-byte (possible address?) argument. The WAb4WDa7RA10 is the write-byte-check-InBusy for the byte a7, The WAb4WD01RA11 is the same for the byte 01. The last part of the command (perhaps the return value?) is RA11 - poll OutReady, and a single byte is read from FPDAT: 00.

If 09 is a command, then perhaps it's a read of the reserved flash. The address used by the first command is a701, the second uses ef01, and has the value 4a returned. All speculation!

This is very slow going. I can hear my wife in the living room asking my daughter "Where is your naughty daddy?". Oh loko at the time! I'd better finish this later!

Following links: Project Euler

I was just trying to update the wiki on Google's code hosting site, where I put the java GDS-2062 utility. I wanted to add an image, to make it look nice, they're worth a thousand words, you know. And this was only 5k in size, so that's a thousand 4-letter words! Anyway, I ended up looking at a page that had no relevance to my search, it just happened to have the search terms scattered about on it. And there was a blog entry for the Project Euler website. The author of the page (Doug Daniels) had posted some Java code, and before I could stop myself, I was trapped. "That looks like it should be easier than that" I was thinking, and then an hour or so of my afternoon disappeared.

Project Euler lists maths problems. The one the author had posted on his blog was to find the sum of the natural numbers below 1000 that are multiples of 3 or 5. Doug Daniels was on the right track - he posted an equation for the sum of a series, and I used it. The answer to the problem is the sum of all 3-multiple numbers plus the sum of all 5-multiple numbers minus the sum of all 15-multiple numbers. Project Euler told me my answer was wrong. Doug had posted the equation shown here, which appears to have at least one error in it. That minus sign should be a plus, and perhaps the n to the right of the sigma should be a k.

I was pleased to see this equation, I remember its derivation in school as a moment of insight. Anyway, I wrote a reply to Doug's blog, explaining the derivation of the formula and a way of writing down the answer as a one-liner in Java. When I submitted my reply, the blog page came back with no indication I'd ever written anything. I would have been happier to have got a page saying "I've /dev/nulled your smug reply, you big-headed tosser". But there was nothing at all...

So you're going to get it, now. That sum of series. You need it to add up all the multiples of 3 and of 5, and of 15 under 1000. There are 333 multiples of 3 under 1000, from 3 to 999, so you can use the sum equation to calculate 3 times the sum of 1-333. To answer the problem, you could sum the multiples of 3, add the multiples of 5, and then subtract one sum of the multiples of 15, because they were in both series.

You need an equation that works though, so how to sum up numbers from 1 to whatever (n as a mathematician would say)? Write the numbers down in a row, 1 on the left, n on the right. Write a zero to the left of the 1. Under the zero, write the same series down, but starting with n on the left, under the top row's zero, and counting down until you write down 0 under the top row's n. If you add up each column (2 numbers in each column), starting from (0 + n) on the left, and ending with (n + 0) on the right, you'll see that every column sums to n. And there are n + 1 columns (because we added a zero column). Adding the zero doesn't affect the sum, obviously, it just helps the maths work out nicely. Look at what you've written down. There are two of the original series, one counting up, one counting down, and the sums of the columns (all the same). If you add all those sums together, you'll get (n + 1) times n. That's the sum of 2 of the original series. Since the two series you wrote down are the same, they must each contribute half towards that big sum. So the sum of the original series must be (n + 1) times n divided by 2. Or if you don't like words in your equations, it's (n + 1)(n / 2).

I've typed this in once before today, so I'm going to give up early this time. Doug's Java code used for loops to sum test each number under 1000 and add it to a total if it qualified as a multiple of 3 or 5. The one liner (split over 3 lines!) is:

public static int pe35sum(int n)
{
return (((n - 1) / 3) * (((n - 1) / 3) + 1) * 3
+ ((n - 1) / 5) * (((n - 1) / 5) + 1) * 5
- ((n - 1) / 15) * (((n - 1) / 15) + 1) * 15)
/ 2;
}

The divide by 2 has been moved to the end. In some places, integer truncation helps this method work. In the case of the / 2, the 0.5 is necessary, as often as it isn't.

I hope this helps!

Java GDS2062 1.0.9 etc

Went shopping at Giant near Senawang today. We took the 'scenic route', but got a little lost. I wasn't bothered, I hadn't been there before, but shopping malls are not exactly nirvana for me. The scenery on the way was marvellous, we can get lost again and it'll be a pleasure. Almost every other place I've been in Malaysia is palm oil plantation all the way, but there were plenty of rubber plantations and some sugar cane, banana and bamboo today. Some of the villages along the way looked lovely.

Anyway, got a couple of updates on the Java scope utility today. It now has some support for setting the trigger, and displays the current trigger status (not really status, still can't get RUN/STOP) very much like the scope itself does. I use extended JLabels for the utility. The earlier ones are all setup by a monolithic refresh procedure that gets all the data from the scope. The trigger has its own refresh method, which makes the code a little bit easier to browse through.

Went fishing for the next burst in the C2 erase sequence, and got it after two tries. Well, I got something after two tries. As I get further into the sequence, the jitter on the bursts may eventually be sufficient that I'll skip a burst and get the next one. I'm still hoping that my answer lies in the early part of the sequence. Today's burst is WAffRDc0. Again, I'm utterly clueless. So the IDE reads 0xc0 from register 0xff - so what?

Ricky from ec2drv emailed more helpful info for getting the USB debug adapter going. I'll work on that tomorrow.

Using Linux with Silicon Labs kit

How long before I do some proper work? A while ago, I tried the ec2drv project's code from sourceforge. I think I made a half-arsed attempt back then, and quickly gave up. Desperate to have Linux back on my laptop today, I tried it again. Whatever has changed in the interim, it comes very close to working. It works for lots of other people, but I have a very recent microcontroller from Silabs (the C8051F530), and the project has yet to add support for my micro. It does recognise it correctly, however, but fails to write it. I've got some code like that! They (ec2drv) also provide an early version of their ddd (GNU debugger) support. That looks quite good, but useless to me until some Linux utility will actually write to this micro. I left a note on the project forum, they were very quick to reply and very helpful last time. I was adamant last time I wasn't going to continue to use the Silicon Labs programming adapter, but I'm stuck with it unless I pay for a better oscilloscope.

I'm not at all sure how they're going to add support for the micro I use. I downloaded SnoopyPro from sourceforge to have a look at the USB traffic between the IDE and the debug adapter. Wow. There's a lot! And little of it made any sense to me. I gave up almost as soon as I started. If someone from ec2drv can give me a few pointers, I'll have another look, but I'm not looking forward to it!

Back to the oscilloscope

The question I had to ask myself is "Do I feel lucky?". But being as I own a GW Instek GDS-2062 oscilloscope, the least debugged oscilloscope in the world and would probably blow... enough of that. I had 30 minutes at the end of the day before I had to deliver on the parental front, so I tried 'fishing' for that elusive third burst of traffic between the Silicon Labs IDE and the C8051F530TB (Test Board, I think). Got it in 4 tries! I wonder how many times I can erase this microcontroller before it's a brick? I think the datasheet said it was in the tens of thousands, so I probably shouldn't worry. There are quite a few commands in this burst.

WAb4 is selecting FPDAT, the Flash Programming Data register. WD01 writes 01 to FPDAT - what's that? I can't find anything in AN127 about it - just about SiLabs' only reference to Flash Programming via C2. AN127 lists 4 command codes that can be writted to FPDAT, but 0x01 isn't one of them. RA00 - a read of the address register gets a status code. Bit 1 is 'InBusy', referring to a write to FPDAT. Bit 0 is 'OutReady'. Since the IDE just wrote 01 to FPDAT, this is telling us the write is finished. RD01 - perhaps this is the result of the WD01? WAb4 selects FPDAT again. RD0d... AN127 uses a read from FPDAT, compared to 0x0d, to check 'FPI Command Status', so I guess this is what this is. RA01 is fetching the status code again, and this time OutReady is set.

The middle line: WAb4 selects FPDAT. RD1b reads 0x1b from FPDAT. Then a read of 4 bytes follows: b4, 87, 00, 5c. RD01 is a last byte of 0x01. The last line: WAb4 selects FPDAT again. RD6d reads 0x6d from FPDAT. RD01 a read of 0x01. WAb4 selects FPDAT again, and reads 0x97. The C2 reader I wrote finishes cleanly at this point, so that means either that the set of samples were good, or they were bad in such a way that they meant something to the C2 reader. But that is unlikely.

Not exactly interesting reading. Perhaps all this will become obvious later. If you're reading this and thinking "Duh! I know what that is!", let me know, please?

Told you the ec2drv guy was good

Replied already, fixed some things, and given me some suggestions of what to try next. Got to go - got work to do!

Agilent. Oscilloscope pr0n

I wish I could afford one of these. I used something like it on a project at a UK university a couple of years ago. Did exactly what you expected of it. Even did some things you wouldn't have expected, but just found yourself wishing an oscilloscope would do. When you looked in the manual, somebody had already thought of it and built it in. Perfectly. I'm having second thoughts about self employment, and third. They're hiring in Penang, loads of people, by the looks of it. I'd post a link, but the Jobs link on their homepage is as easy for you to find as it was for me. I'd better get back to work instead of dreaming about how easy life would be with an Agilent scope.

If only...

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.

Scope utility on google code

That ought to have been easier than it was. It's not that it's difficult, there are hints everywhere. Given the hints, the first things I thought of happened to be wrong almost every time. Oh well, the scope utility is available for download from Google code hosting. The source is also available at http://code.google.com/p/gds2062/.

Past my bedtime again. Perhaps just a few morsels:

C2 snooping

Was having trouble correctly reading the C2 traffic between the IDE and the microcontroller. Extracting the sample points using the java utility and plotting with GNUPlot, it's obvious that the C2K (clock) strobe leads the C2D (data). Looking at the C2 Interface specification from Silicon Labs, I see that... that's what the manual said all along. A small change to the C2-reading code, and the utility seems to get the snoop right on all the datasets (not many) I've tried so far. I did try straining my brain first - I was expecting C2D to be setup before the strobe leading edge, perhaps triggered by the strobe's falling edge. But it isn't. Should have RTFS.

Problem with GW Instek GDS-2062 command language

I sent an email off to Instek in the U.S. (I think) today. There's one guy who works for them, that answered once. That's when I was told there would be a firmware update in February. I'm still waiting for it. I think it's going to be a good one. Instek have a lot of websites, with a lot of email addresses and contact forms. I must have sent half a dozen messages or so when I first got this scope to ask for help. Not a dicky bird. Except for the aforementioned bloke. So I've sent him a couple more. This latest one is about the USB/serial port command language for the setting the time/div. You use :TIMEBASE:SCALE and provide a floating point number like 2.5e-3 to get 2.5ms per division on the oscilloscope screen. Only it doesn't always select the right settings - probably a typo in the firmware code, I suspect. Here's the list copied verbatim from my email:

Command (Result)
:TIMEBASE:SCALE 1e-3 (1ms) correct
:TIMEBASE:SCALE 2.5e-3 (1ms) wrong!
:TIMEBASE:SCALE 5e-3 (2.5ms) wrong!
:TIMEBASE:SCALE 10e-3 (5ms) wrong!
:TIMEBASE:SCALE 25e-3 (25ms) correct
:TIMEBASE:SCALE 50e-3 (50ms) correct
:TIMEBASE:SCALE 100e-3 (50ms) wrong!
:TIMEBASE:SCALE 250e-3 (250ms) correct

If you're doing something with a GDS-2062 via the USB/serial port, you might run up against this feature!

That's it. Bed calls.