OK, started with OPC's receiver (which is pretty nice) and got something working - a simple echo system (also setting the 6 LEDs to low bits of the character processed).

https://tildegit.org/stack/Tangnano9K-UART

Seems pretty stable, with a tiny bit more effort on the status side will do.

Thank you for your great suggestions and feedback!

Excellent news.

While we're here, a reminder of a hardware design for a simple uart (send and receive!) viewtopic.php?f=4&t=8020

I assume (yeah, I know!) this would be easy to translate to programmable logic?

Neil

The latest usable uart tx and rx are in this repo https://tildegit.org/stack/Tangnano9K-65c02-experiments in the parts directory.

I am going to delete the uart repo.

I spent 12 hours tracing down a horrendous bug, which has to do with the UART receiver, as it turned out.

I originally assumed it was in my Tugman CPU, which is completely experimental. I had some very occasional weird crashes, so I knew there was an issue somewhere. Finally I had a consistent crashing system -- adding a NOP in the beginning fixed it. And so the hunt began, turning into an agony. The code that crashed is the monitor I'm writing, so seeng thing was difficult.

I tracked it down to a bit missing, $FFF turned into $7FF, but only at location $14B. And only if the 4-byte sequence following it was followed by $10C or $30C (this is an 18-bit CPU). Actually $3FFFF turned into $3D7FF. There are other locations but I didn't have time to find them, or felt the need to-- that seemed like enough. I assumed it had to do with the loader, and constructed meticulous tests to check each instruction, and eventually, what is being written, and eventually realized that the UART rx is choking. Although I still cannot explain the exact mechanism of this failure.

Taking the datarate from 115200 baud to 56K fixed one of the bits, and 38400 sems to get everything right.

Since the UART is very close to OPC, keep that in mind!

Ah, so no change to logic, just a decreased useful baud rate? That is of course interesting...

(Thanks for posting your discovery and debug story though - always good to read such an adventure.)

Ed, correct, no logic change. Apparently the timing was marginal, and occasionally failing. It's almost explainable with turning FF into F7, but the D from F is a little harder to explain. I suspect I may have to revisit the UART sometime soon.

I always had suspicions about clocking in bits with fixed timing, as it doesn't quite work out perfectly, but it seemed to be working. 27MHz divided by 115200 is 234.375, and for some reason I subtracted 1 resulting in 233 clocks (and to sample in the middle, rounding yet again). In some documents 27MHz is actually 27.027MHz so I was running the UART too fast, I suppose. I can probably get it back to 115200 by playing with the timing, or shifting the sample offset from exact middle forward or back, but for now I am just happy to not have bits missing.

There is another possibility: the bit may not be triple-flopped on input, or rather it is being sampled after two flops for transition. This may cause the input line to go metastatic very, very occasionally, which is what's happening. Except it's consistent, so probably not. But, perhaps the conditions with surrounding bits are just right...

Also my butt hurts from sitting all of yesterday.

I had another nearly-identical issue at 38400 baud. Without a scope or a frequency counter I am working blind, but tweaking the numbers, got it (apparently) working (for now) at 115200 by pretending that the clock is 26MHz and sampling 200 cycles in. It's like whack-a-mole here.

Are you sure you're seeing and syncing on the start bit in a good way?

Also, is your 'rs232' a local TTL/CMOS signal travelling just a few centimetres, or a real +/-12v signal with level conversion between the two ends? Is is possible that it's introducing noise into the signal? (Your lack of a scope might make things tricky there.)

I suppose best practice to detect the start bit would be to first to use a Schmidt trigger to clean up the initial edge, then to wait (using an x16 clock reference) seven clocks, sampling three successive clocks and assuming a valid start only if all three are low. Then repeatedly wait sixteen clocks to sample the nominal centre of incoming bits (or better, if you reset the sample counter after the start bit sample, sample on counts 13-14-15 and again only take it as valid if they all agree).

But that said, for a short link at TTL/CMOS levels, generated by something like a USB converter, the precision of the incoming signal will be very close (timed by the 24MHz USB clock) and the close distance will do away with any noise unless you've done something really silly like missed an earth...

Neil

̶Y̶e̶a̶h̶,̶ ̶t̶h̶e̶ ̶U̶A̶R̶T̶ ̶r̶x̶ ̶i̶s̶ ̶d̶e̶f̶e̶c̶t̶i̶v̶e̶. Now that I have a monitor, I can fill memory with alternating 3FFFF and 0010C (probably anything with a 0 byte will work), and every so often I get 7's insted of F's.

I have to find another minimal UART or make one. This one has some other problems -- changing baud rate has a drastic negative effect (20%+) on fMax, likely due to overuse of combinational logic.

The USB circuit is on-board, within millimeters away from the FPGA. However it is not hardwired, it is a Chinese RISCV SOC masquarading as a CH340 or something like that (somehow that's cheaper?), so it is possible that it drops bits all on its own or has uncertain timing. God, I haven't even considered that.

My last theory of the on-board USB interace failing seems to be right.

I replaced the UART received with a different one, and it's producing similar bit drops.

Yikes. I suppose I can use raw IO pins with my own USB-serial adapter when I get back to my lab.

In the meantime I will try a few things.

From my perspective, it would be good for the problem not to be the OPC-like UART!

Me too, actually. GIven the nearly-identical behaviour with both receivers, I think the OPC UART is likely fine.

I also sent the data very slowly into the loader, flushing the output each time and delaying. Same result, so it's not an inter-byte timing problem...

There is a slight chance that my CPU misses bits on an lshift, which is really ADD TOS,TOS, or OR? but very rarely? And always in the same place? Seems unlikely.

Now, I do get different bits missing when I change the UART-RX timing constants, so that is relevant. And it's seems to be the same exact locations that are affected during the load.


It's always at $18C, dropping 2 bits in this configuration. Moving the base of the loaded code a couple of bytes does not change the position of the error, so it is not likely to be the loader screwing up the load. I am pretty sure it gets that from the UART...

Here is another vector, with $7F0C interleaved, with a slightly different result


It does look like some kind of a shifting issue, doesn't it? Unfortunately both the UART and the CPU shift data.

Could the BRAMs be flaky? Memory is synthesized as 9 2-bit BRAMS, so it seems possible that two bits would be affected (yeah, but two different bits?). Data is from TOS, so it's registered and stable, but the address is coming out of the ALU_B combinational logic. It should settle early and not really be an issue, but it is possible that one of the BRAMs is getting a bad address on write under some conditions I cannot fathom.

I am going to try to construct a test with individual bytes from the UART instead of relying on the loader...

Did you have similar issues with the Arlet 65C02 based system?

If the issue is the USB UART, I would expect it to be independant of which CPU you use.

Also, what happens if you run the system at half the clock speed?

Dave

At 8MHz the small bit of memory I was examining looks fine. At 16, the problem re-appears with a vengeance:



I will pursue the problem here for now -- I have a clear and repeatable error situation. My 65c02 system has an entirely different memory layout and everything else... Perhaps a bit later if I can't figure it out here.