Key File System Driver Serial Port Problem

jazzed · 2011-02-20 13:17

I'm using the file system driver for testing:

&#9474; SD2.0 FATEngine Demo                                                                                                        &#9474;
&#9474;                                                                                                                             &#9474;
&#9474; Author: Kwabena W. Agyeman                                                                                                  &#9474;                              
&#9474; Updated: 6/16/2010                                                                                                          &#9474;
&#9474; Designed For: P8X32A @ 80Mhz                                                                                                &#9474;
&#9474; Version: 1.0                                                                                                                &#9474;
&#9474;                                                                                                                             &#9474;
&#9474; Copyright (c) 2010 Kwabena W. Agyeman                                                                                       &#9474;              
&#9474; See end of file for terms of use.                                                                                           &#9474;
&#9474;                                                                                                                             &#9474;
&#9474; Update History:                                                                                                             &#9474;
&#9474;                                                                                                                             &#9474;
&#9474; v1.0 - Original release - 6/16/2010.                                                                                        &#9474;

I find at 100MHz or 104MHz, the Propeller sometimes receives bad characters on the serial port at 115200 baud. This does not happen with FullDuplexSerial (and friends) at up to 104MHz on any board.
It always happens with the File System Driver on any board in my office at 100MHz +.

Since I plan to offer the 96MHz and 104MHz crystals in a product, I would appreciate it if the problem could be fixed.

kuroneko · 2011-02-21 16:25

The serial driver used chokes on single cycle jitter as it may be sampling during bit transitions.

jazzed · 2011-02-21 17:06

@kuroneko, thanks for looking at the driver. The 2.0 package driver is super-ceded by the 3.0 driver and all remnants of the bad driver appear to now be gone from OBEX. Apparently I picked up the 2.0 driver over the last few months just before it was replaced.

kuroneko · 2011-02-21 17:10

So why is revision 1.6 of the COM driver still [post=979004]advertised[/post]? Besides, rev 1.6 is included in the SD3.01 demo package as well (which is where I got it from initially).

jazzed · 2011-02-21 17:32

kuroneko wrote: »

So why is revision 1.6 of the COM driver still [post=979004]advertised[/post]? Besides, rev 1.6 is included in the SD3.01 demo package as well (which is where I got it from initially).

Are you sure it's the same code? The filesystem 3.0 code seems to work. The revisions are the same in both files, but doing a diff is impossible without first getting rid of the silly parallax font. Guess i have to get iconv (again) for sure now.

kuroneko · 2011-02-21 17:38

Well, I did yesterdays test with the version extracted from the SD3.01 package

jazzed · 2011-02-21 18:00

I do believe your analysis. I guess if i type enough characters I may see the problem again. With the 2.0 version the problem appeared within the first 8 or so characters. iconv utterly fails to convert the new file from UTF-16 but converts the old file just fine so i guess there is some small difference, but I'll never know what it is.

kuroneko · 2011-02-21 18:03

Do you still have the version extracted from 2.0 (attach)? As for actually suffering from the bug, it's about 1.3%, i.e. a very small timing window.

jazzed · 2011-02-21 18:07

kuroneko wrote: »

Do you still have the version extracted from 2.0 (attach)? As for actually suffering from the bug, it's about 1.3%, i.e. a very small timing window.

Yes, I'm attaching it. A Root Cause Analysis of failure is the only thing that puts questions to rest, so it is very useful to follow through all the way.

kuroneko · 2011-02-21 18:18

They differ in what I'd like to call whitespace changes. Meaning the SD3.01 contribution is in ASCII mode, your version is strictly UCS-2. Why on earth isn't the revision up'd (both are 1.6)?

Anyway, the PASM section in question is the same. I ran the test again with both drivers and they show the same issue although at a different offset. So your test timing may have just moved out of the DMZ to not see it

jazzed · 2011-02-21 18:24

Maybe there was *interference* in the old SD2.0 package. For whatever reason the SD3.01 package is better (except for having to reformat for the darn thing to work). It just has to be left as "iffy" at this point. I guess it's good that MIT license does not guarantee function. How can we have a "Gold OBEX" with the MIT wording? Oh boy. Maybe some things are more gold than others. LOL.

Kye · 2011-02-21 19:54

... Ask the author much? The reason the SD3.01 FATEngine required you to reformat your SD card is because it WAS corrupted. The SD3.01 driver is ALOT more robust than the version 2.0 driver. Have faith in the DS3.01 driver, it is really, really, good - expect for the speed issue, which I will tackle soon.

Sorry for yelling.

I just use the RS232_COMEngine because I never have probems with it. I accept though that it does not work perfectly and that trying to use the waitcnt statments in it make life hell. I'll get arround to fixing that driver sometime... when I have time.

@ kuroneko - My serial driver is not broken by design. But it is not robust by design either. I use a 4X sample rate and align myself to be somewhere in the 1/4 to 1/2 bit width area. My driver does not sample the bit in the middle of the period so it chokes when data is not pretty much perfect... using the waitcnt statement pretty much kills FDX functionality, you can't get speed and precision at the same time. I'll have to recode the driver.

I'll get on recoding that then. I won't included it in anymore releases.

(I'll be lazy and just remake FDX with my interface)

jazzed · 2011-02-21 20:14

I posted this question for anyone including you to answer. Don't act like a child.

Kye · 2011-02-21 20:17

Not trying to. Thanks,

jazzed · 2011-02-21 20:20

Kye wrote: »

Not trying to. Thanks,

Sorry. I shouldn't have said that.

Kye · 2011-02-21 20:29

No problem. Sorry, when I get defensive the regulation filter comes off and what I say is usually a spew of consciousness.

Anyway, I will fix the serial port driver in all future releases and very soon. Version 1.6 of the serial driver is the best I can do (and I think anyone else and still hit 250_000BPS) using waitcnt statments. If I increase the timing to 8X in the driver the problem will probably go away, but the max speed will decrease.

Chip's FDX serial driver is the way to go I guess for the propeller. Even though it has horrid bit timing.

kuroneko · 2011-02-21 20:37

Kye, the problem is not 4x or 8x, the former is just fine. The issue is when the start bit falling edge appears just after the second start bit test (carry flag). This means it has to go round the loop again which effectively wastes 3/4 of the bit. Then the first test catches it (zero flag) but wastes another 1/4 bit time before sampling the bit during its transition. This also means that if the incoming bit time is just 1 cycle off (12.5ns, that's 0.14% at 115k2) you get corrupted data.

Dr_Acula · 2011-02-21 20:49

I have to confess that I too had some problems here. I never really wanted to mention it, but it is the reason KyeDOS has Tim Moore's serial driver code in it rather than Kye's serial driver. The problem manifested itself with huge xmodem file downloads (100k) and there was a failure every 20k or so.

kuoneko seems to have found a possible cause in post #17

Kye · 2011-02-21 21:20

Yeah, that driver hurt my brain alot when programming it... It took alot of thinking just to get the code to work. If I can add a third sample period I should be able to fix the issue. The reason I didn't in the code is because for it to run at 250_000 BPS I had to cut the code down to the bone.

kuroneko · 2011-02-21 21:32

@Kye: Why don't you spread the two start bit sample points to be 1/2 a bit apart instead of 1/4 (tx test between them)? With an extra 1/4 bit advance you're still within 1/4..3/4 of the bit time.

Cluso99 · 2011-02-21 22:32

Here are a couple of suggestions. Sorry I don't have time to help atm.

1. Cut the code back to 115,200 by all means. But 115,200 is used a lot. Above this, we can do something else, or fix it later.

2. Is there any way to use a counter (kuroneko?) to start counting the start bit once it is received. I think it's highly possible. That way, you can detect how much time was lost when you detect the start bit, and take that into account. This may well fix the problem, because the timing would then be synchronised properly to the start bit.

kuroneko · 2011-02-21 22:41

Cluso99 wrote: »

Is there any way to use a counter (kuroneko?) to start counting the start bit once it is received. I think it's highly possible. That way, you can detect how much time was lost when you detect the start bit, and take that into account.

Certainly, in the end it's all down to how much effort one wants to put into it.

Cluso99 · 2011-02-22 03:02

kuroneko:
Is my understanding of the counters correct?...
If the counter were set up to add frqa (=1) to phsa (+1) each clock when the start bit arrives (is active), then it would be a matter of clearing phsa each time the code enters the wait for start bit. Once a start bit is detected, read phsa to see how many clocks have passed to be used in calculating the sampling for the middle of each.
So the counter would be set to Logic !A (start bit =0 for non-inverted mode) or Logic A (start bit =1 for inverted mode).

If this is correct, I will have a go of putting it into FullDuplexSerial_rr004.spin - this version can have variable buffer length in ^2 sizes. I have a unverified version that checks for CTS. So it would be a good start to updating the FDX. Maybe reclaim the hub space for the buffers too!

kuroneko · 2011-02-22 04:49

Cluso99 wrote: »

So the counter would be set to Logic !A (start bit =0 for non-inverted mode) or Logic A (start bit =1 for inverted mode).

Sounds OK. Either those modes or POS/NEG.

Kye · 2011-02-22 07:17

The problem with using counter modules is that they work no better than just sampling the bit line.I've tried.

You need more instructions to read them robustly and if your reading the counter modules during the bit transistion time stuff goes wrong.

@ kuroneko - Will do.

Cluso99 · 2011-02-22 13:50

Kye: I was thinking only to accurately detect the beginning of the start bit. This should be reliable and it should not then be required to resync on each bit on the way through. We are using a crystal, so the timing should be accurate enough provided the start bit is sensed accurately.

Key File System Driver Serial Port Problem

Comments