Something is working

I wouldn't be impressed if somebody fixed my car this way, but lo and behold, a little progress at last. I got completely lost up my own problem looking at the output from usbmon. I gave up on javax.usb in the end - it wasn't the right tool for my job. Some of the driver examples look impressive, so beyond the difficulty in installing it, I'm looking forward to using javax.usb again in the future. I don't need a driver though, I just want to check that the drivers I have are working correctly. By the time I'd written a java utility to parse the contents of /proc/bus/usb/devices (what devices are connected to my Linux system) and /sys/kernel/debug/usbmon/*t, I'd more or less got the hang of reading the text contents by eye. Well enough to see that my GW Instek GDS-2062 wasn't making complete replies to commands to its serial port.

I didn't know what to do after that, so I looked again at the driver issue. When I connect the oscilloscope to the Linux system, it's 'recognised' as a USB modem. Perhaps this is a fault of the oscilloscope's vendor and product ids being set incorrectly? So I used rmmod to remove the cdc_acm module and modprobe to load the usbserial module, specifying the scope's vendor and product ids on the command line. I did it slightly differently this time, specifying that the ids were in hexadecimal format:

modprobe usbserial vendor=0x0558 product=0x2009

Coupled with a change to the way I'm reading the (USB) serial port from my Java scope utility, it all seems to mostly work. At least well enough for me to get back to my original problem, which was the C2 communications between Silicon Laboratories' IDE and their prototype boards. I'm trying to get the C2 programming facility hosted by one of their microcontrollers (so one micro can program another). The change I made to the Java code was a reversion to some older code that waited around too long (in my opinion) for the remote system to finish sending data. Either the change of USB driver, or the extra delays in the Java program have made the previous problem (truncated replies and scope lock-ups) go away. I'm making hay while the sun shines. If the problem rears its head again, I'll try to take better notes as I go along, so I can deduce what the solution really is.

I've got some dread lurgy on my scalp and in my ears at the moment. Yes, I do wash. It's making it difficult to concentrate, so I'm giving up for today after posting my first successes with the Java utility. Can I attach an archive to a post? It doesn't look like it, perhaps I'll post it elsewhere on the web. If you're really desperate, reply this blog, and I'll send it to you.

Java scope utility

On my desk I have a Linux desktop that I do most of my work on. Next to it I have a notebook running Windows. I don't want to use Windows, but at the moment I don't have an alternative for flashing the Silicon Laboratories microcontroller prototype boards I have. There is the ec2drv project at sourceforge, but I don't want to use the Silicon Labs debug adapter for my project. Not because there's something wrong with it, I think the adapter and the prototype boards are good products at good prices, but it's just not appropriate for my design. So I'm stuck with Silicon Labs' IDE for now. All my programming and compiling is done on linux, using SDCC.

After following the C2 application note from Silicon Labs, my boards gave no sign that flashing was going to work. Looking at the oscilloscope traces, the code on the board sending the C2 commands seemed to be right. Checking against the Silabs IDE, well, that's not so easy. A lot of traffic goes between the IDE and the target board, for even simple jobs such as resetting the system. My oscilloscope, full of natty features, a great price, doesn't work very well. A pity, it looks like it could, with a bit of firmware programming effort. So I wrote a Java utility to help me out. It's quite useful already - I don't have to get up! The scope is almost a metre away from where I sit, so I could lean over and with a bit of reaching, hit the Run/Stop button. But it's right next to the 'Auto Set' button, which should do something useful, but it appears to me to just completely randomise all settings. The scope works well enough to tell me that the 'reset' button in the IDE does quite a bit more than just pull the C2K line low.

The trace is imported from the scope, and is a fairly good likeness, except that you can see more of the sample buffer. The big red box in the middle is a select box I've drawn with the pointer. Right-click on it, and I've added a 'Read C2' option that converts the two waveforms to C2 commands. The program's output for this waveform is:

RESET
C2Reader: WA02WD02WD04

The reset is obvious, but the IDE software then writes address 0x02 (the flash programming control), then writes data 0x02, 0x04. I'm basing what follows on an assumption: that these codes are the ones referred to in AN127 "Flash programming via the C2 interface" as the key codes that enable C2 flash programming. They're different codes from those in AN127. But why do I have to do all this to find that out? I'll search silabs.com again to see if there's a misleadingly named application note wich tells me what I really, really want to know. I'm resisting the urge to shout. Good, aren't I?

It takes a bit of fiddling about to get the right time scale and offset for the scope to deliver useful samples for reading C2 commands. They're delivered very fast from the debug adapter. Too fast for a snoop program to run on the microcontroller (tried that). Using the Java utility though, I can set the time scale / offset, sample memory length and run/stop mode from my chair. How useful is that! I'd better go and do some exercise to make up for it.