My Traditional FTDI Uart Interfacing Problem

[biomed12]

Hello dear all,

I need help about the uart interfacing of FT2232H dual serial channel chip.

I am woking on a motor controller project. I use a control card from TI for the first prototyping. It has a FT2232H chip which has dual channel. The first channel is connected to C2000's JTAG port. It works great via the Code Composer Studio while debugging. I want to use the other channel as UART-USB interface and it's pins are connected to the MCU. I configured everything as aspects of both hardware and software.

The problem that I have always had the problem with FTDI chips is the data from MCU to PC are corrupted with %7-8 error. What is the thing what I am doing wrong always with those? I always feel really nerveous when I work those chips.

There is a member who is mastered on ftdi chips but I could not remember his name. I need you sir, please hear me:)

Thanks!

[PICker]

I worked with FTDI chips both in normal and Bit-bang modes without problems. I dont know the FT2232H but it is possible that you did some errors in the MCU UART routines.
Your description is too generic and it is difficult to figure out the problem with so few information.
Try to reconfigure your serial ports, and, as last possibility, change the FTDI chip in case of defective units.

[Gallymimu]

what does "corrupted with %7-8" error mean?  Are those ascii characters over the port?  are those errors at the USB device layer in windows?

[bogdantk]

First you should look at power supply. Is it a local one or from USB bus? In my experience FTDI chips are very reliable and ease to use but you need to provide a clean power supply without glitches and voltage dips. Star with a very good decupling (electrolitic + smd)of power supply pins

[biomed12]

Sorry for the weak information, let me explain.

I am trying to communicate that control card with the PC.

The data frame format like that: 4 'f' char byte to start data exchange after a blan char every four bytes contains one parameter.

For example, ffff 1000 2000 .... In this frame the ffff is the start part, the 1000 integer is the first parameter(data), the 2000 integer is the second parameter and so on.

code:

char sendData[18];
int arg1 = 1000, arg2 = 2000;
sprintf(&sendData[0],"ffff %d %d",  arg1, arg2);

BUT,

The incoming data to PC is like that

-> ffff 1000 2000
-> ffff 1000 20
-> 00ffff 1000 2000
-> ffff 1000 2000
-> fff
-> f 1000 2000
-> ffff 1000 2000

The frame is corrupted as you see. Data is not lost but not at the format what I send. I had experienced that problem with the FT232RL chip before. I am sure that the chip is OK. I do not know what I do wrong. Also I tried different serial terminal programs.

The HW configuration is:

FTDI              MCU
-----              ------
Rx      <->       Tx
Tx      <->       Rx
RTS <--
           |
CTS <--






Posted on: January 17, 2018, 07:24:39 07:24 - Automerged

what does "corrupted with %7-8" error mean?  Are those ascii characters over the port?  are those errors at the USB device layer in windows?

For example I send 100 data frame(I dont mention about uart frame), average 7-8 frame is not at correct form.

[PICker]

good: You do not have data loss.
bad: the serial packet are fragmented.
The problem can be at MCU level or at PC level.
If you develop a serial piece of software at pc level you can flush the receiving buffer after data reading.
From your information the problem seems to be at MCU level (the output buffer seems to be not correctly flushed at every send cycle).
Try to insert your sending code in a for loop (i.e. 10 cycles) and put a delay instruction after every send function.
Check also the correct number of stop bits in port configuration.

[Sideshow Bob]

I would suggest some sort of buffer overrun

[tumbleweed]

There is no "frame". Basically, data will stream out of the port as a series of bytes, not packets.
There is nothing to guarantee that the data from one sprintf command will all be in one usb packet.

It is working properly. Your application must read bytes until it determines that it has a proper message,
however you define that.

[dennis78]

It is very possible that you have problem on PC side (driver, chipset driver, os, or combination of this, maybe some type "hardware incompatibility"). Did you try on another PC (desktop, laptop). I work with FTDI many times without big problems, but I have few times problems exactly like this. Problem was on only specific PC and I never explore real reason for that because I didn't have time for it... Do you have another type of USB/UART converter? Maybe PL or CH module just to try...

Try this: on device manager go to specific com port go to properties->advanced settings and change latency time on minimal value and increase buffers size on bigger value. Also, try to put terminal program on high cpu priority and look is any changes... Of course, select no handshaking option

[pickit2]

I would say power supply problem, or driver.
was there an issue with fake chips, that the driver killed the chip.
the company I used to do work for stopped using them, as there was too many fakes.

[biomed12]

Dear all,

Thanks for all replies. The problem is probably at the PC side. But also, I think hardware handshaking is required, RTS-CTS. I updated the driver but it did not changed.

But I solved the problem in the software of the pc side. Now, it works great. I hope, it will go the same.

My method to solve problem is to wait until my custom package is received completely. For example, I send 15 bytes from MCU. I wait at the pc side until 15 bytes are received.

Thanks.

[towlerg]

Glad to hear that you have fixed your problem. I don't know how you are receiving the 15 byte string but for a similar project I used standard SDK ReadFile and WriteFile running in a separate thread. If you set nNumberOfBytesToRead to 15, all you have to do is test the return value = 0. Given the limitations of the multi tasking, windows runs surprisingly well. I just realized you did not specify your OS but I'm sure equivalent functions exist in Linux et al

[PICker]

At PC side you can implement a not-blocking approach by using an event-driven callback routine (i.e. onDataReceived)
with some synch chars at line start or (better) at line-end (EOL). A classical EOL sequence is CRLF ("\r\n") in C.

[fpgaguy]

When you get this "corrupted with %7-8 error" - is that from the ftdi driver, chip, or your application ?

[Gallymimu]

From your description this is a framing problem that is most likely a problem with your programming.  Usually the "ffff" would be used as a frame sync.  Other methods would be time between frames, or frame length (though with frame length you still need a frame resync from a timeout or a start character or byte),

Since I don't understand how your PC program is making the decision about line separations I can't offer further comment.

This is a common problem.  I think it is unlikely to be any sort of power issue as that would corrupt individual bytes in most cases.

I also would not use CTS/RTS.  Those aren't really needed in modern systems that have FIFOs and fast response times to relatively slow serial transmissions.

[biomed12]

When you get this "corrupted with %7-8 error" - is that from the ftdi driver, chip, or your application ?

I think, the problem is stem from the driver. Because, different serial terminals give the same result. 

Posted on: January 18, 2018, 06:59:42 06:59 - Automerged

From your description this is a framing problem that is most likely a problem with your programming.  Usually the "ffff" would be used as a frame sync.  Other methods would be time between frames, or frame length (though with frame length you still need a frame resync from a timeout or a start character or byte),

Since I don't understand how your PC program is making the decision about line separations I can't offer further comment.

This is a common problem.  I think it is unlikely to be any sort of power issue as that would corrupt individual bytes in most cases.

I also would not use CTS/RTS.  Those aren't really needed in modern systems that have FIFOs and fast response times to relatively slow serial transmissions.

I use Qt and its serial port classes. But different terminals give the same result. In the past, I had that problem again, when I used FT232RL chip while I was working on my final year project at the senior of bachelor's. There is a topic at the FTDI forum also: http://www.ftdicommunity.com/index.php?topic=40.0

[PICker]

I suggest you to use the amazing tool https://sourceforge.net/projects/scriptcommunicator/
Ii is QT based and you can do rapid tests in few seconds (also using javascripf for complex packets)

[Gallymimu]

you still haven't addressed the issue I brought up.

how are you expecting the QT serial drivers to know where the start and stop of a data frame are?  I doubt your built in drivers have any ability to determine what line should be which.  This is normally something up to the programmer to parse and figure out.

I think you are expecting the drivers to know when there is a new line.  How is it supposed to know about that?!

If you don't implement a data packet framing method (timed, start char, packet size) then it can't possible know what you want.  The fact that you have been getting packets on each line is probably just coincidental and not by design.

[biomed12]

you still haven't addressed the issue I brought up.

how are you expecting the QT serial drivers to know where the start and stop of a data frame are?  I doubt your built in drivers have any ability to determine what line should be which.  This is normally something up to the programmer to parse and figure out.

I think you are expecting the drivers to know when there is a new line.  How is it supposed to know about that?!

If you don't implement a data packet framing method (timed, start char, packet size) then it can't possible know what you want.  The fact that you have been getting packets on each line is probably just coincidental and not by design.

Dear Gallymimu,

My framing method is that:

ffff <arg1> <arg2> .. <argn> '\0'

ffff is the start string and NULL is the finish char. The input buffer size is 97 bytes which includes start and stop strings.

I do not send continuous data from MCU. I send 5 frames per second.

I developed a method at the PC side which is like that:

When any data in the input buffer is available, then my Qt C++ program is triggered with a mechanism called signal-slot and goes to a method which is named as readData(). There are the two scenerious.

First, my frame is received completely and input buffer that is sized as 97 bytes is full. So, read the full frame to readBuffer[97].

Second, input buffer is not full of 97 bytes of data. It is continued to fill. So, my program waits until input buffer is empty(there is no data to read) and keeps going to read incoming data to a buffer.

After one of them, send readBuffer[97] to parsing method, this algorithm works great now and solved my problem.


Best Regards.

[Gallymimu]

Good glad it is working.  It sounds like what I said was the problem.

I would normally fill the buffer until a timeout, if I get a timeout before a full packet you flush the buffer, keep flushing the buffer until you see the start character (and restart the timer) this is a normal way to maintain framing.