Close

(Not) Receiving Serial Data

A project log for Yet Another m68k Homebrew

A full-featured Motorola 68k homebrew, this time with a 68010 running at 8MHz

Ross BamfordRoss Bamford 08/12/2019 at 20:280 Comments

I've grown tired of pulling the ROMs for programming every time I want to try something in the firmware, and having managed to kill one of the ROM chips while doing so (ESD I guess) I decided the time was right to hook up the 68901's Serial In line to the cp2102's TX line so I could hook up a simple Zmodem implementation, allowing me to send code to the running board via the serial link. The idea behind this is to allow me to more quickly iterate on the firmware that will eventually interface with mass storage devices and such.

Unfortunately, having been at it now for a couple of days, I just don't seem to be able to get it to work. No matter what I do, the 68901 just doesn't respond at all to input.

To begin with I built the new code into the async serial driver and set it up so that the whole thing would be interrupt driven (by the RX Error and RX Buffer Full vectors), but it didn't work. The interrupts were never generated.

(As a side note, in the course of doing this I did come across a bug in the serial transmit code that caused it to silently die after the first time the ring buffer becomes completely empty, which is now fixed, so that's something at least).

For sanity, I went back to basics and wrote a simple 'echo' program in pure assembler that didn't bother with the interrupts at all, and just did polling on the RX Buffer Full and TX Buffer Empty. Still nothing - the MFP never sets the buffer full flag.

Getting desperate, I hooked up the probe to the SI line and ran a few-seconds of trace while I pressed keys in minicom, and sure enough the UART decoder in PulseView showed the data was getting there just fine. I did this because I was worried that Minicom's hardware flow control might be causing problems, even though I have the cp2102's CTS line grounded right now (eventually I'll drive it from one of the MFPs GPIO lines but for testing grounding it should be just fine).

I tried lowering the baud rate (all the way down to 4800), switching from the fundamental clock mode to the divide-by-16 mode (which I know can make a difference to receivers), and finally I decided to port someone else's code (actually, the monitor program from the awesome Rhombus project: https://hackaday.io/project/8725-rhombus) to my board, in the hope that their working code would show me what I was doing wrong.

This isn't a perfect test as I've had to make some changes to the MFP initialisation code (my clocks are different frequencies to Rhombus and I don't have any compatible crystals at the moment) but I've only changed the timer frequencies and switched from using two timers on the MFP to just having one timer driving both TX and RX clocks, which is the way my hardware is set up (as I write this, I'm wondering if/how that might be the cause of the problem...?).

Anyway, to cut a long story short, it doesn't work, in exactly the same way that my own code doesn't work. Right now, I don't have any idea why.

I'm going to take a break from this tonight, and hopefully have fresh ideas tomorrow. In the meantime, if anyone's got any ideas or suggestions I'd love to hear them - hit me up in the comments :)

Discussions