SUART transmit issue: Garbage char/byte drop at receiver end

The maximum baud rate is 115200.  I believe that setting the default baud to 230400 forces the underlying HW to run at that speed even if you run the physical interface at 115200.  Try setting the default baud to 115200.

Hi Gus Martinez,

I appreciate your quick help. Thank you so much.. !

I also tried with default 115200 baud rate, it also gives me byte drop at 115200 baud rate.

I suspect, the byte drop/garbage character is due to baud rate mismatch.

For 115200, CLKXDIV = 0 (value = 1), HCLKXDIV = 208 (value = 209) gives baudrate = 114832.53 which is not close to expected value 115200.

Equation is ACLKX = (AUXCLK)/(CLKXDIV * HCLKXDIV) = 24 MHZ/ (1*209)= 114832.

Is there anything, I am missing somewhere ?

Is it possible that data is not latched properly at some point, due to clock not matching to desired value and resulting in data corruption in McASP transmit ?

Please suggest.

Thanks,
Sweta

That's less than 1% error, I doubt a baud rate mismatch is the issue.  Have you used the latest release?  

Hi Gus Martinez,

I am using the release from http://www.mistralsolutions.com/pes-support/support-downloads/l13x-daughter-card-documentation-software.html

I downloaded patch file latest available from this site and applied it on DaVinci-PSP-SDK-03.20.00.12 release kernel and followed all steps to build suart_emu.ko module.

Please suggest if there is any other release.

What I have observed is, with 8x Oversampling and default 115200 configuration in driver, it works fine for 1200, 2400, 4800 baudrates.

Where as, starting from 9600 onwards, up to 57600, it gives 1 byte corrupted for 11 KB data transfer.

For 115200, the bytes are not corrupted but are dropped.

We have designed our own daughter card for this, the only change is RS232 transceiver MAX3221ECPW chip. But I don't think this error has to do anything with such corner case error. Reason is, it works well and error rate is very low.

Has anyone thoroughly tested this driver for data consistency and load ?

I have one more que: Why not to configure McASP for various baudrates every time ? I tried this as well, could see better result but couldn't make it 100% work for all baudrates.

For 115200, if I change HCLKXDIV to 207 instead of 208, then it transmits well without any error for 115200. But since it is relative baudrate, it affect few other baud rates which were working properly.

Please suggest if there can be any issue at receiver end ? How it is tested, was it linux application or standard terminal program like teraterm or hyper terminal ?

What should be setup requirement ?

Thanks,
Sweta

Can you try setting your transmitter to use two stop bits or to add a delay between characters?

Hi Gus Martinez,

Today I took the default release and modified the application to send data in chunk of 500 bytes. Write call to driver will be done at every 1 second interval.

With this, I could transmit 500 KB data consistently at 115200 baudrate. However if I use the same chunk size for 57600 baudrate, it shows me 16 consecutive bytes corrupted after 180 KB successful transfer.

So what I observed after various experiments is, chunk size has some relationship with data transmission at a given baud rate.

It will be of great help, if someone can share the application package with which, this driver is tested for different baudrates.

That will help me to analyze what can be the restriction/issue.

Inserting delay between every write call doesn't fix it 100%.

Thanks,
Sweta