It is difficult to imagine what's going on without seeing your circuit and project.
But I noticed a couple of things which may cause problem(s)
(1) I assigned the Tx and Rx pins to the correct outputs,
Please assign Tx to an Output and Rx to an Input.
(2) although it is choppy and lags between strings for about 2 seconds each
As soon as I transmit "Foo\r\n" to the PSOC, I get an endless stream of newlines back from the PSOC.
In my experience, when I mistook Tx and Rx, sometimes it shows similar symptom.
How about double check if your
"TX" of PSoC device is connected to the "RX" of your PC or the host
"RX" of PSoC device is connected to the "Tx" of your PC or the host
and last but not least, please connect GND between the PSoC device and the host.
Firstly, you should guarantee that the hardware connection is Ok. You should try to substitute the Tx &Rx connected DuPont Lines, connect GND between the PSoC device and the host.
CE224406 could act as the UART code example in PSoC4100.
You can use below two sentences to replace the uart_polling project man loop.
/* Start UART operation */
/*Places a byte of data in the transmit buffer to be sent at the next available bus time.*/
I checked the hardware connections, and did as you suggested, and replaced the while loop as listed above. I tried it both with and without the UartPutString lines included in the example project.(I am working with the "polling" project in CE224406).
Below you can see the output when I ran the code you indicated with the UartPutString lines included. The output works both with and without those lines, and it displays a new "a" every second as expected.
When I remove the UartPutString lines form the original project file, and leave just the code to read and respond to incoming characters. When I do that, it sits patiently until I send anything from the tty, then it goes into an infinite loop of transmitting new line characters. When I run the PSOC in debug, it looks like the calls to UartGetChar() are returning data from the *transmit* buffer instead of the receive buffer. Every time I call UartSendChar(), the character is transmitted, but the character is also placed in the *receive* buffer. I thought this might be a loopback problem with my tty, but I ruled that out by completely disconnecting the Rx pin on the PSOC and pulling it to ground. In that configuration, any character that I put in the transmit buffer also gets placed in the receive buffer. It is almost as though it is using the same location for the transmit and receive buffers.
I have not changed the pin description that the project uses as default. (In the project, the pins are not shown in the schematic and are only available in the pins window. The 4124PVI only allows 2 locations for the Uart pins: 11/12 and 15/16. I am using 15/16. The Uart input (host to Psoc) must be on pin 15, and the output (Psoc to host) must be on 16, and that is how I have it wired. The circuit layout is below:
The host header is for a "standard" raspberry pi header. Note that it is reversed because this is a bottom side mating connector for the Rpi header. I have verified this layout, and was using this same circuit previously using the I2C pins on 3 and 5, and that worked 100%. The only thing I am changing for this design is moving from I2C to Uart communications between the host and the PSOC.
Also note that the PSOC board actually provides power and ground to the host through the P1 header and the HH3 and HH4 mounting holes.
Lastly, I am 100% certain that the Uart wires are correctly hooked up because when I take out all attempts to read from the Uart, and just write, I get good output on the tty (rpi), and when I take out all writes and just read from the tty, I get good data. The only time I get trouble is when trying to use both together.
The trace length from the PSOC to P1 is approximately 20mm, and then an additional 15mm high connector to the rpi. Also note that I have the same problem at any Uart speed from 110 Baud to 115200 Baud (I have not tried higher).
I just started feeling that the sample project was not correctly re-targeted.
I created a simple project which shows a startup message then echo back all the data typed.
Could you test it, if it works differently?
P.S. Since the mid-night is approaching in Japan, I need to go for today,
I also attached a version "B" which uses interrupt.
And ported from my sample at
I have also re-targeted this project to CY8C4146LQI-S433,
which is the closest device I have a test board
and connected it via KitProg and tested.
At least the project worked in my side.
You said " It is almost as though it is using the same location for the transmit and receive buffers."
I suppose this is a cross-talk, RX input is electromagnetically induced by TX output.
Please try pull-up the RX pin to VDD because the idle state of the UART signal is logic high.
The phenomenon that received characters are destroyed seems to be caused by the baud rate mismatch. When you open the Component Configuration Tool invoked by double-clicking on the UART instance, you can see following hover message.
This is displayed when the actual baud rate is too different from the ideal baud rate. The difference can be reduced by adjusting the oversampling rate to 13 as follows.
Or more slower baud rate is used like 19200
I thought the baud mismatch might be a root cause, so I tried using 110 baud, which is a perfect match, and the behavior is the same (but slower).
I also tried using a pull-up to VDD as you indicated, and this did not change the behavior.
As a side note, I tried compiling and targeting the project by wiring a CY8CKIT-059 dev board. The sample project works perfectly on the PSOC5LP dev board. I do not have any CY8CKIT-146s or I would try that. I have ordered a few CY8C4244PVI-442s and will try one of those chips as soon as they arrive.
Now I'm positive that your PSoC is receiving something from the Pie.
So let's see what has been sent from the Pie.
Would you try attached project and let us see the result?
The project is modified so that it will show "non printable" chars as hex decimal.
So we should be able to see if same bytes are being sent or some random binaries
are being sent.
Meantime, I would like to ask you to try a loop-back test.
Would you try connecting Pie's tx and rx with a jumper wire and try typing something?
Will it show only what you are typing or are you getting similar runaway lines?
If you see runaway lines without PSoC, the problem resides in the Pie or host side.
If you see only what you are typing, then I think that the problem should be between Pie pins and PSoC Pins.
I hope I am using the appropriate greeting . I tried the loopback on the PI, and there is clearly something unexpected with the tty I was using (loopback produces the same run-away problem). I switched to use the minicom tty instead, and now all of the PSOC sample programs are behaving correctly. I appreciate your help in this matter. I suspect the old tty was trying to implement some kind of software flow control that I was unaware of.
Thank you again for your help in this matter.