A Workaround For The Uart Bug

[Zerosquare]

Here's a little idea I had to circumvent the Jaguar's UART bug.

 

The ZIP file contains a detailed description and a demo program (the source code is included).

 

Enjoy !

TestUART.zip

[Zerosquare]

Version 1.01 is now available. I updated the file in the original topic.

[TXG/MNX]

Version 1.01 is now available. I updated the file in the original topic.

 

Can we expect a DOOM patch someday ?

[ovalbugmann]

Thanks Zerosquare.

[SebRmv]

Hello,

 

these days, I have powered up my Jaguar and played a bit with the UART controller.

On my PC, I used putty to communicate on the serial link with the Jag. (I have a RS232 cable plugged in the Jaglink2 on the Jaguar side)

 

I observed that the parity bit in ASICTRL has the opposite meaning of what is said in Jag_v8. Am I the first one to observe this?

(i.e. when bit #0 of ASICTRL is set to 1, and parity control is enabled, even parity is active)

 

I also observed the problem of corrupted characters (left shifted by 1 bit).

However, the error bits of the ASISTAT register seems to be set correctly.

So by just clearing the errors and dropping the received character, I guess it is easy to recover from this error.

(this seems to work in practice)

 

This means that a simple protocol to transmit packets over UART would work.

(I mean transmitting packets on an unreliable channel is doable, if not everything is lost of course!)

 

Are there any other bugs I should be aware in the UART? If yes, how can I trigger them?

 

For the moment, I programmed the UART just by polling the ASISTAT register on the 68k side.

I intend to experiment a bit with the DSP interrupt and try to see if I can get something working using these few observations.

 

Has somebody already tried these ideas? (I guess yes, but we never know)

[SebRmv]

I played a bit this night and unfortunately, it is not that easy!

 

The receiver seems to become deaf if we stress it too much and I have not found the way to reset it until now.

 

By the way, it is quite cumbersome to set the UART interrupt handler.

Actually, it is the GPU that processes the request coming from Jerry.

(IT handler at GPU_RAM+$10)

 

 

 

 

[Zerosquare]

The receiver seems to become deaf if we stress it too much and I have not found the way to reset it until now.

Indeded, that's the problem I had too, and I couldn't find a way to reset it either. So I decided to forgot about the broken UART receiver completely and do it in software

 

PS : glad to see you back on the Jaguar

[SebRmv]

Indeded, that's the problem I had too, and I couldn't find a way to reset it either. So I decided to forgot about the broken UART receiver completely and do it in software

 

Ok. I finally understood what you did (or maybe I understood before but forgot since that time ).

 

But Software UART, nobody wants to do that in real life, doesn't it? (especially when a hardware chip is supposed to do it!)

 

And did you notice this thing regarding the parity?

 

I can't make sense of the remark in the "known bugs" sections about UART where they describe a possible workaround.

In particular, I don't understand the following:

 

"Subsequent bytes should be exactly aligned (i.e. 2, 3 or 4 stop bits exactly, before the next start bit)"

 

Can you make sense of that? I suspect the key is there.

 

How is it possible to transmit several stop bits?

[Fredifredo]

Yeah ! Sebrmv is back

 

[sh3-rg]

Yeah ! Sebrmv is back

 

\o/

[Zerosquare]

But Software UART, nobody wants to do that in real life, doesn't it? (especially when a hardware chip is supposed to do it!)

Why not, if it works fine ?

(in embedded electronics, it's not rare to emulate features in software when the hardware is buggy -- or too expensive to afford)

 

And did you notice this thing regarding the parity?

Nope, but IIRC I always used the "no parity" setting, so I probably didn't run into it.

 

I can't make sense of the remark in the "known bugs" sections about UART where they describe a possible workaround.

In particular, I don't understand the following:

 

"Subsequent bytes should be exactly aligned (i.e. 2, 3 or 4 stop bits exactly, before the next start bit)"

 

Can you make sense of that? I suspect the key is there.

 

How is it possible to transmit several stop bits?

The stop bit level and the idle level (when you're not transmitting anything) are the same. Which means (for example) that sending a byte with 1 stop bit, then waitng for the duration of 2 bits before sending the next byte, is the same as sending the first byte with 3 stop bits.

 

What they mean is that the delay between incoming bytes should be an integral multiple of the bit duration. If that's true, that means that if you send a continuous stream of bytes, you should never run into the problem ; that would be interesting to try.

If it works, it would be easy to work around the problem : when you don't have anything to transmit, just send "filler" bytes to keep the UART busy.

(note that it's problematic for network with more than 2 consoles for collision reasons)

[SebRmv]

Why not, if it works fine ?

(in embedded electronics, it's not rare to emulate features in software when the hardware is buggy -- or too expensive to afford)

 

Yes, I know that, since I work in a company that does embedded platforms.

But I feel it is a waste of DSP power until I got the proof it is impossible to do an other way on the Jag.

Do you think other people that did a workaround for the UART bug uses a method similar to yours?

 

The stop bit level and the idle level (when you're not transmitting anything) are the same. Which means (for example) that sending a byte with 1 stop bit, then waitng for the duration of 2 bits before sending the next byte, is the same as sending the first byte with 3 stop bits.

 

What they mean is that the delay between incoming bytes should be an integral multiple of the bit duration. If that's true, that means that if you send a continuous stream of bytes, you should never run into the problem ; that would be interesting to try.

If it works, it would be easy to work around the problem : when you don't have anything to transmit, just send "filler" bytes to keep the UART busy.

(note that it's problematic for network with more than 2 consoles for collision reasons)

 

I have not understood.

[SebRmv]

I think I found something!!!!!!!!!

 

It does not work yet, but I think I am on the way to get a workaround. So maybe someone here can experiment on his own.

 

While taking my shower, I had the crazy idea to write back the ASICLK value every time I get in the UART receiver interrupt (just before leaving interrupt handler).

 

Here are the details of the experiments.

 

On the PC side, I set my serial port to 57600 bauds, even parity control.

 

On the Jaguar side, same thing.

 

On the PC side, I launch the simple script:

while true; do echo -n "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" > /dev/ttyS0; done

 

With my patch, the UART receiver is alive during more than 10 seconds (I got more than 1 minute several times, my record is maybe 3 minutes)

 

Without my patch, the UART receiver dies very quickly (a few seconds in the best case)

 

I also observed that the duration of the liveness depends on the length of the message transmitted. (for the message "0123456789abcdef", it lasts only a few seconds)

[SebRmv]

I also observed that the duration of the liveness depends on the length of the message transmitted. (for the message "0123456789abcdef", it lasts only a few seconds)

 

No, this actually seems to be the message content!

 

If I send "aa", this works a long time.

If I send "01", the receiver dies quickly.

 

[Zerosquare]

Interesting...

 

But with your script, a delay can occur between two "echo" commands. I think you should try something like "cat big_file > /dev/ttyS0" (big_file being a few megabytes for example), or a small C program like this :

 

#include <stdio.h>

int main(void)
{
    char buffer[] = "0123456789";
    FILE *f = fopen("/dev/ttyS0", "wb");
    for (;;)
    { 
        fwrite(buffer, 1, strlen(buffer), f);
    }
}

[ggn]

This is all very interesting

 

Just out of interest, I found the send/receive code on doom, if Seb gets something stable running I could try hacking it into doom (of course someone with 2 Jaguars, 2 Jaglinks and 2 skunkboards should have to do the tests )

[SebRmv]

Well, I think I am still quite far from getting a "light" workaround (if such a thing is possible).

 

By the way, what happens in Doom when network crashes?

[sh3-rg]

This is all very interesting

 

Just out of interest, I found the send/receive code on doom, if Seb gets something stable running I could try hacking it into doom (of course someone with 2 Jaguars, 2 Jaglinks and 2 skunkboards should have to do the tests )

 

/me holds up his hand, but politely requests the return of 1 jaglink

[ggn]

That's what we got on one of our tries at Outline 2010:

 

 

Although I do recall a message saying something like "link lost"

[SebRmv]

But is Doom crashed? Or is it possible to play again (alone and/or over the nerwork) without resetting the Jag?

[NooB]

The only way to recover from the 'network crash' is to reset the Jaguars.

If I remember rightly, ggn and sh3 were trying to play some of the hacked

Doom II levels that I did. Some of them are larger and more complex than

the original levels, but I doubt this would have had any ill effect on the

already bugged network code.. extra data due to the larger more complex

levels.

[SebRmv]

The only way to recover from the 'network crash' is to reset the Jaguars.

If I remember rightly, ggn and sh3 were trying to play some of the hacked

Doom II levels that I did. Some of them are larger and more complex than

the original levels, but I doubt this would have had any ill effect on the

already bugged network code.. extra data due to the larger more complex

levels.

 

Thanks for the info

[TXG/MNX]

The only way to recover from the 'network crash' is to reset the Jaguars.

If I remember rightly, ggn and sh3 were trying to play some of the hacked

Doom II levels that I did. Some of them are larger and more complex than

the original levels, but I doubt this would have had any ill effect on the

already bugged network code.. extra data due to the larger more complex

levels.

 

Thanks for the info

 

Is this topic dead or has someone done some more testing or maybe did found a good solution ?

 

Secondly did one of you manage to patch doom to be more stable ?

 

[Zerosquare]

I don't think anybody ever tried to modify the Doom serial code.

[Matthias]

Hello all!

 

I don't think anybody ever tried to modify the Doom serial code.

 

My excuse is:

At the time when the mentioned workaround was discussed i only had one JagLink as i had forwarded the second to another developer, but then i bought a new JagLink package from Nick at Euro-Jagfest 2011, but focussed on getting Impulse X released (and this job is still not finished).

 

Best regards

Matthias