Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

PSoC™ 5, 3 & 1 Forum Discussions

RaAl_264636
Level 5
50 sign-ins 25 sign-ins 10 solutions authored
Level 5

Hi,

I'm using a CY8CKIT-059 in combination with TeraTerm. One thing I can observe when downloading a new binary is that the KitProg UART gets a bunch of garbage and confuses TeraTerm, which needs to disconnect and connect again.

Interestingly, other tools behave different:

YAT: gets just a few characters including escape sequences
HTerm: same as YAT
PuTTY: can't see any garbage

Currently it looks like the effect pops up mostly if the application sends UART messages after reset by itself (e.g. without receiving a message first and then send an answer), but I've to verify that. I assume that when KitProg is resetting the device within a character transmission, the application might interpret it as some escape sequences or something like that. I also can see the effect at a much lower rate and much less garbage if the application doesn't send anything at startup, so even transmitting nothing is not the (full) solution.

Disconnecting and reconnecting is not a big issue, it's simply annoying if you've to do it everytime a binary is downloaded. Since also YAT and HTerm show at least 'some effect', I want to suggest that the KitProg firmware disables the UART while downloading a binary.

Regards

0 Likes
14 Replies
Srivastav
Moderator
Moderator 100 sign-ins 10 likes received 5 likes given
Moderator

Hi @RaAl_264636 

When you say garbage value, is it the case that you are observing random characters getting printed on Tera Term? Can you please share the screenshot of the same?

Can you please verify if you have set-up the baud rate correctly in Tera Term in Setup>serial port same as that of in the UART Configurator in the PSoC Creator? 

 

Thanks and Regards

Arpit Srivastav

0 Likes
Len_CONSULTRON
Level 9
1000 replies posted 750 replies posted 500 likes received
Level 9

RaAl,

I've this issue come up with other comm programs as well.

However, the issue might be the target PSoC as well.  When you program the FW on the target you are using the SWD interface which is different from the UART interface through the KitProg,  

When the target PSoC is reset, the UART Tx port goes from an output to an input until it is changed back to an output after power up initialization.  This could cause a data 'birp" where certain comm programs get confused.

I noticed that if I use the PSoC USB_UART for UART comm, I don't get these 'garbage' issues.

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
RaAl_264636
Level 5
50 sign-ins 25 sign-ins 10 solutions authored
Level 5

Hello,

sorry for the late reply.

@Srivastav 
Of course the baudrates are correct in both PSoC device and TeraTerm as well as in the other tools mentioned, otherwise the communication with the application wouldn't work 😉

Attached it a screenshot of the garbage. Here are the steps I did:
1) the already loaded binary had no output at the beginning, it waits for input from terminal first and then sends on UART
2) I inserted a printf() statement right after configuring the UART component
3) Downloaded binary. NOTE: At this point there's no garbage since the old loaded binary did not output anything to the UART, so you can see a clean output of the new binary => see line 1 of the screenshot
4) just downloaded the binary again from PSoC Creator without any modifications => line 2 and following of the screenshot

@Len_CONSULTRON 
Yes, that's my assumption that toggling the reset line (which is obviously necessary to get the device into debug/programming mode) will cause the Tx pin to burp, so thank you for confirmation of the effect. It's also no question that this pin toggling will be recognized by the terminal application, that's physic 😄 I just wanted to suggest that the KitProg device will disable the UART Rx pin during binary download, so that the burping Tx pin won't cause lockups of any software using the KitProg UART. Re-enabling the Rx pin should occur just before releasing the reset pin - I assume at this point the circuit should be stable.
Regarding USB-UART, here the USB pins might burp as well, but I assume the USB hub controllers and also the underlying drivers of the operating system will catch such errors. I'm pretty sure that during the device reset the USB will simply detect a device dettached event, e.g. the same effect as pulling out the device off the USB slot.

Regards

RaAl_264636
Level 5
50 sign-ins 25 sign-ins 10 solutions authored
Level 5

@Srivastav were you able to reproduce the issue?

Regards

0 Likes
Srivastav
Moderator
Moderator 100 sign-ins 10 likes received 5 likes given
Moderator

Hi @RaAl_264636 ,

Can you please use printf("\x1b[2J\x1b[;H"); as \x1b[2J\x1b[;H - ANSI ESC sequence for clear screen and see if you're still getting garbage values. ANSI ESC sequence to clear screen could solve the issue. You can refer to https://github.com/Infineon/mtb-example-psoc6-uart-transmit-receive/blob/master/main.c CE and see that it was used before printing anything. Unfortunately I was unable to replicate the issue but generally this is the way to clear the garbage value. If our way of understanding of the issue is not correct then please let us know the way to replicate the issue

Kind Regards 

Arpit Srivastav

0 Likes
RaAl_264636
Level 5
50 sign-ins 25 sign-ins 10 solutions authored
Level 5

Hello @Srivastav 

I already tried that because the current project is indeed using VT220 sequences. Clearing the screen by this way is not a 100% solution for several reasons:

  1. At least for TeraTerm it is not enough, because if the "garbage" switches TT into a Kanji mode or something like that, this can't be resolved by simply clearing the screen. As already written, sometimes it's needed to disconnect and reconnect to TT, which is also an indicator that clearing the screen (or the buffer within TT application menu command) is not enough
  2. Consider the situation where you're connected to a serial monitor application which doesn't know anything about VT220 sequences - this would confuse the user since he would see the plain sequence. The same applies to any dedicated application using the UART and where the device is updated with e.g. Cypress Programmer application.

So, in general you understand the issue correctly, but I think your solution is the wrong way because it enforces to solve it by the application. On the other side, I assume this situation is very rare on fully developed end products because they won't incorporate KitProg + UART by default.

You wrote that you were not able to replicate the issue. According to your provided source code you're using a PSoC6 device, right? Please use a CY8CKIT-059 as I do just to be sure that we have the same environment.

Regards

0 Likes
MotooTanaka
Level 9
First comment on KBA 1000 replies posted 750 replies posted
Level 9

Hi,

I have encountered the same situation so many times.

Unless they (Infineon/Cypress) provide solution in KitProg firmware level,

I'm afraid that fixing it 100% would be very difficult.

 

Although I agree that the following solution is easy and handly and usually works,

 

UART_PutString("\x1b[2J\x1b[;H") ;

 

I tend to use the following method which seems to work slightly better.

 

void cls(void)
{
    print("\033c") ; /* reset */
    CyDelay(20) ;
    print("\033[2J") ; /* clear screen */
    CyDelay(20) ;
}

 

moto

 

0 Likes
RaAl_264636
Level 5
50 sign-ins 25 sign-ins 10 solutions authored
Level 5

Hello Moto,

thank you for confirming the behaviour. The additional sequence is a soft terminal reset sequence. Using VT control or escape sequences might be a workaround for a given setup, but I doubt that it will always work: even if the receiving application supports clear screen command etc, there's a chance that the reset sequence is not implemented. That assumption fits to my observation for the different terminal applications - it seems that they're working differently internally, otherwise the effect should be the same for all those applications.

As already pointed out, I think KitProg firmware should be modified. Additionally, I've to check if pull resistors on the UART lines will be helpful.

Regards

MotooTanaka
Level 9
First comment on KBA 1000 replies posted 750 replies posted
Level 9

Dear RaAl_264636-san,

>  Additionally, I've to check if pull resistors on the UART lines will be helpful.

Yes, I was also thinking about it.

The symptom looks like the UART pins are left open during the configuration,

then having weak pull-up may take care of the problem.

But I'm sorry I was too lazy to test it.
So I definitely love to hear your test result!

Best Regards,

7-Oct-2022

Motoo Tanaka

RaAl_264636
Level 5
50 sign-ins 25 sign-ins 10 solutions authored
Level 5

Hello @MotooTanaka 

I added 6k8 pull resistors to both P12.6 / P12.7 (Rx & Tx) and VddIo. Test setup is CY8CKIT-059, nothing attached. Used component is UART with 115k2 baud rate, nothing else. System clock is 72Mhz based on USB-enabled 24Mhz IMO. Software just initializes the UART and spits out a single line of text.
And this test is performed on a different computer to ensure that it's not related to a specific computer.

You can see the result in the attached screenshot. Lines 1-6 show the already described behaviour. From line 7 onwards (after red separating line) the output with attached pull resistors is shown - there are much less garbage characters. I assume the remaining garbage characters are from resetting the device during transmitting a character.
So, the pull resistors help, but they don't catch 100% - there's still a chance that the garbage character is interpreted as a special control character confusing the attached software. Nevertheless, this is a big and important finding because we're currently talking about KitProg UART, but in fact this may hit any UART application. 

@Cypress: I assume there are no plans to modify CY8CKIT-059 circuit - then the pull resistors could be added, too. But at least you now can ensure that future designs incorporate those pull resistors. So we're back on modifying the KitProg firmware as an easy option to get 100% coverage. I assume that KitProg FW will get an update sooner or later anyway, so it could be merged.

And now: time to modify ~20 pcs of CY8CKIT-059 😆

Regards

BiBi_1928986
Level 7
500 replies posted 250 replies posted 250 sign-ins
Level 7

Hello Motoo.

Thanks for the testing and observations.
Could you try one more test: use pull-down instead of pull-up.
I'm curious if continuous 'break' will make a difference.

RaAl_264636
Level 5
50 sign-ins 25 sign-ins 10 solutions authored
Level 5

@BiBi_1928986 

No problem, good idea. See the attachment. No changes in test setup or firmware except for using external pull-down instead of pull-up. So, it looks like even the last garbage character has gone, there are just two space characters now (I assume those are spaces, maybe needs verification with logic analyzer). So, pull-down seems to be the preferred workaround.

Regards

MotooTanaka
Level 9
First comment on KBA 1000 replies posted 750 replies posted
Level 9

Dear RaAl_264636 san and BiBi_1928986 san

Thank you very much for the suggestion and testing!

I was not imaging that 'Break' can contribute,

this was a very nice learning!

Best Regards,

8-Oct-2022

Motoo Tanaka

P.S. Well, still we (the users) are hoping that someday the firmware of KitProg will take care of this 😉

0 Likes
RaAl_264636
Level 5
50 sign-ins 25 sign-ins 10 solutions authored
Level 5

Hello @MotooTanaka 

Yes, that was indeed very interesting and helpful. I fully agree that the KitProg firmware should be modified.
I hope they'll come back to this topic with positive feedback.

Regards