Friday

Started: 2002-06-28 19:38:33

Submitted: 2002-06-28 20:32:07

Visibility: World-readable

For the record, the purpose of this changelog is to record what I accomplished today so I can read it again whenever I resume work on my project. The idea is that I can come back up to speed faster that way.

(I still have no really good idea what I'm going to do. But I have a plan that I haven't entirely rejected yet. Maybe this changelog will have some cathartic effect, although not likely nearly as cathartic as the epic e-mail I typed late last night, which I may edit and paste here sometime soon.)

I double-checked that the examples provided by Analog Devices really truly do break. I poked at them a bit (changing them slightly from their original form, but nothing that (in my opinion) should really change anything) and it definitely still breaks, with the same error message, "Critical section timeout":

EZLAB Error Code 0x20000007 occured in function TWaitingCriticalSection::Lock(1000) returned: Critical section time out

I really didn't want to *call* tech support (since I'm afraid of talking to strangers on the phone, especially if I'm going to be demanding things of them), so I e-mailed them again, following up to their pathetic response, and asking directly for the cause of the error and what can be done to fix it.

I decided to try to get my Ethernet driver working (or at least see how far I could get) without the use of printf(). I resolved that I could use the debugger as long as I didn't try to step over anything; setting breakpoints and running to them was ok, and single-stepping assembly instructions was ok. I could get feedback from my code by investigating local variables. Crude, but hopefully sufficient.

As I expected, it was a minor pain to convert my code, which previously relied on providing feedback to me through printf(), to breakpoints at the right places and variable investigation. In general, I prefer the first approach; I can write code to process data for me and present it in some format that I'll understand, and maybe ignore. I have an audit trail of what has happened. This is a pain to do in the debugger. (In this situation, I don't really see why the DSP has to know how to do printf(); couldn't it just send the variables to the host PC, which would then format and display them, like it does with local variables and other stuff while the debugger is stopped?)

When trying to read the first thirty-two bytes from the Ethernet chip's memory, which should be the station address PROM, I consistently got all zero's, then four 0x57's at the very end. From reading the kernel source (which was invaluable in my understanding Ethernet drivers), this suggests three things: (1) My chip has no station address; (2) I really am reading from the right region of memory, as suggested by the 0x57's at the end; and (3) The chip needs to be interfaced with in sixteen-bit mode; trying to do byte-wide I/O will cause it to send repeated data items. (If true, that could be a Really Big Problem, since the Ethernet board I'm using will only let me get to eight data bits. I doubt this is really the case, though, since apparently other people have no trouble using this board in eight-bit configuration. Perhaps I'll have to grok their source (unfortunately, for 8015 assembly, which is a little harder to dramatically read than C) as well.)

I attempted to set the station address PROM myself, but I failed, and didn't try very hard to get it to work. I attempted to send bogus Ethernet frames, which usually (but not always) generated a transmit successful interrupt. I couldn't see any compelling evidence that a frame was actually being sent over the wire, however. I ran tcpdump on Elssbett, connected via a (homebrew, so it might not actually be working) crossover cable, but failed to see any frames at all. I plugged a straight cable into a hub and didn't see the hub blink at all. I found another homebrew crossover cable in the diglab that had the neat feature of having been made from a straight cable, which had been cut open at one of the ends and cut and spliced so four wires were available for my observation. I attached oscilloscope probes to them and tried to figure out what I was looking at. I discovered what appeared to be a heartbeat signal. Further investigation revealed that I could trigger the signal at a negative voltage, which would capture a real Ethernet frame, and only an Ethernet frame. I plugged this into my development Ethernet chip but failed to get anything. (My initial theory was perhaps the chip was indeed generating a frame, but because I was running the chip at 3 volts (which the DSP wants as its I/O voltage) instead of its rated 5 volts, Elssbett's Ethernet card couldn't distinguish it from line noise.) I failed to get a transmit success interrupt when I did that, however. I put the code to wait for a transmit success interrupt inside a for loop, to count how long it took to receive the interrupt and bail if it was taking too long, and consistently got the interrupt in 0x96 cycles.

Failing the proper resolution of the DSP development issue, I will likely use Clark's EZ-ICE unit to interact with the system, and possibly attempt to get a serial console running on the development board's serial port so I can have a good idea what's happening on it.

Stirling seems reticent to let me get away with declaring my project done without exhausting all of my options. I think I'll go on vacation now, and come back to finish it off.