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!