Serial communication reliability

[remz]

Hi coders, I am having some trouble trying to identify a rare random occurrence of a lost byte during serial communication, and I would like your lights and guidance.

Question 1)
I often see code with a double-write to INTREQ to clear the relevant interrupt flag, for example in my serial receive buffer full interrupt routine, at the end:
move.w #$0800, CHIP_BASE+INTREQ
move.w #$0800, CHIP_BASE+INTREQ
This appears to be apparently for "68040 compatibility": is that a fact or a myth?

Question 2)
The reason I am asking is to validate the tiny possibility that in between these two writes to INTREQ, would it be possible that another byte could have been received on the serial port, with this second write potentially clearing out the flag too soon. Since the interrupt code here didn't reach RTE yet, would the interrupt be ignored and lost?

Question 3) Might be directly for Toni / WinUAE, but any insights would be appreciated:
On WinUAE when testing two Amiga with a serial link connection (using the option -s win32.serial_port=INTERNAL_SERIAL), I saw in WinUAE code that when using this internal serial emulation, winUAE runs in "safe_receive" mode, which we can see it the function:
static bool canreceive(void)
{
// don't replace data in SERDATR until interrupt is cleared in safe receive mode
if (safe_receive) {
if (intreq & (1 << 11)) {
return false;
}
...
My question is, based on that behavior, if I understand properly, it should be "impossible" to lose a byte since WinUAE politely waits until INTREQ is cleared before injecting a new byte. I cannot explain would I seen to be losing a byte occasionnally. Perhaps it is on writing instead of receiving. But in order to diagnose better I would need to have a WinUAE compiled with SERIALDEBUG=2 probably :|

Thanks!

[hooverphonique]

1) yes, this is normally required if you clear intreq just before rte (see 2).. also add a nop after the intreq writes to make sure instructions execute in-order on 060 (otherwise it could 'rte' before the writes are commited to the bus.

2) I would try clearing intreq at the start of the isr in order not to miss interrupt requests that arrive while you process the interrupt.. so the very first thing to do in your isr is to read the received byte, then clear the intreq bit.. then probably also check if the irf is set again before exiting your isr, and process the byte there instead of having to fire the isr again immediately..
If your isr takes a bit of time, the double write to intreq is probably not needed then (as paula will have processed it before your isr reaches rte)..
How much of an effect this change effectively has depends on the size/runtime of your isr, of course..

Edit: you can check for overrun using bit 15 in SERDATR, btw..

[paraj]

Originally Posted by hooverphonique

1) yes, this is normally required if you clear intreq just before rte (see 2).. also add a nop after the intreq writes to make sure instructions execute in-order on 060 (otherwise it could 'rte' before the writes are commited to the bus.

nop is not required for 060 (anymore than for 040 anyway) assuming MMU/TTR isn't setup wrong.


I don't know exactly which models require the "double ack" (and can't find the thread right now unfortunately), but I'm pretty sure it's sufficient to EITHER ack int + nop OR ack int + do other custom reg access.


I.e. it's not that first ack is lost, but rather RTE could exit too quickly and still see old (non-acked) IPL value. nop fully guaranteeing bus transfer is done or another custom access providing extra delay should both be fine.


On my B1260/50 single ack + RTE works 100% of the time.


@OP: One thing to note is that despite WinUAE generally working very well, I found that it didn't behave similar enough to a real machine when debugging corner cases of "high speed" serial transfer (maybe things have improved or my setup was wrong)


Also you mentioning interrupt routines and lost bytes makes me a bit suspicious. Are you sure the routine is called and completes in time? hooverphonique suggestion of monitoring of OVRUN is good.

[hooverphonique]

Originally Posted by paraj

nop is not required for 060 (anymore than for 040 anyway) assuming MMU/TTR isn't setup wrong.

Good to know - I don't have an 060, but heard recently that nop was required to avoid occasional double isr execution due to out-of-order execution.

Originally Posted by paraj

I don't know exactly which models require the "double ack" (and can't find the thread right now unfortunately), but I'm pretty sure it's sufficient to EITHER ack int + nop OR ack int + do other custom reg access.

I.e. it's not that first ack is lost, but rather RTE could exit too quickly and still see old (non-acked) IPL value. nop fully guaranteeing bus transfer is done or another custom access providing extra delay should both be fine.

I have an A4000/040 (C= cpu card), and it suffers from this problem (well known symptom is vbi running at "double speed").

I know the ack isn't lost, I was just playing along with the OP's suggested way of overcoming this problem - I'm not sure just adding a nop between clearing the irf and rte is enough on the A4000 though..

[paraj]

Originally Posted by hooverphonique

I know the ack isn't lost, I was just playing along with the OP's suggested way of overcoming this problem

Yeah, just added the "ack isn't lost" comment for others who may have that idea.

Originally Posted by hooverphonique

I'm not sure just adding a nop between clearing the irf and rte is enough on the A4000 though..

Probably whole NOP thing is cargo cult. I've just seen it a lot, and assumed it would fix it. 100% sure way should be to ack interrupt early, and ensure >2CCKs have passed before RTE - usually "free" by other work but double ack would work if interrupt routine isn't doing anything else.