PSoC4: UART strangeness with example code | Cypress Semiconductor
PSoC4: UART strangeness with example code
In a recent project I used a UART (SCB implementation) at very high baudrate 921600.
running the PSoC @ 36MHz and oversampling of 13 gives nice within tolerance baudrate... anyway in this project I run into some unforseen problems (who doesn't ;-) below is one of them...
I have a project in PSoC Creator 3.1 (did not test any other version) and a 4200 prototype kit, programmed with a miniprog3.
the project just instantiates a UART (SCB) and will echo all incoming data back to the host (PC). simple right?
The UART is configured with a large software buffer (128 characters) and in the testbench I make sure the data to the PSoC is throttled (never causing a buffer overflow etc...)
I am using the UartgetByte() API because I really would like it to work fully transparant (including the \00 character !)
Digging in the API one can read that bits b15-b8 are used to report errors and thus can be used to detect the 'no data' situation since we are polling...
my test approach is simple, use a good serial terminal program and verify that "what goes in must come out" and to my surprise it does not work... I use an application called terminal and it allows the same data to be transmitted periodically, thereby throttling the datarate. text "0123456789" repeated every 100ms. by playing with the horizontal window size it's possible to align every new line and easily visually spot problems... every once in a while only the first character is missing, reading back a 0123456789123456789012345... Now I do understand async data transfers, and maybe maybe frame error ?
if ((UART_data&0x0000FF00)==0) // test b15-b8 for errors
// no error, just echo the data back
HOST_SpiUartWriteTxData(UART_data & 0xFF);
if I change the line "if ((UART_data&0x0000FF00)==0)" with if ((UART_data&0x000000FF)!=0)
thereby disregarding all reported errors and repeating the test, it never fails! (and in doing this it will never echo the \00 character anymore, thereby killing the transparent echo.... could have used UartGetChar() API...)
So now I'm left with 2 of questions:
1. What's the meaning of the error bits b15-b7, the API function does not specify that..
2. is the SCB more likely to get a frame error in 1st character?
3. so is that a problem with the PSoC or the Cypress usb-to-serial converter available on the prototype kit?
4. has anyone seen this before and has a solution ???
// I have checked the timing with a seleae logic16 and it sure looks like good data, no hickups etc....