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!