You are here

PSoC 4 Reads UART fine for couple minutes then stops completely until restart | Cypress Semiconductor

PSoC 4 Reads UART fine for couple minutes then stops completely until restart

Summary: 7 Replies, Latest post by smbullet on 06 May 2015 10:05 AM PDT
Verified Answers: 0
Last post
Log in to post new comments.
smbullet's picture
12 posts

  Hi All!

This is my first time posting so I'm not sure if my file project upload is correct. I'm also new to using PSoC's in general.

I'm designing paddle shifting in an automotive system with two PSoC 4's for and I'm having trouble with the communciation between the two. I have two boards, one that uses the PSoC 4 prototyping kit ( that we will call the "Main Board" and one that uses a PSoC 4200 on a custom PCB that we will call the "Shifting Board". The Main Board takes 3 digital inputs from the steering wheel (up shift, down shift, and clutch) and puts that data into a mesage that gets sent out UART. The Shifting Board reads UART and when it sees that it contains a message to shift, it performs a series of digital writes to actually complete the shift.

What I'm observing:

First of all only one of the solenoids are firing but I will get to that later. Anways, it will work fine anywhere from 10-50 shifts (slowly getting less responisve) and then stop working completely until the Main Board gets restarted. Restarting the Shifting Board does nothing.

My theory:

Since the message I'm sending is larger than the hardware buffer size (4 bytes?) I might be continuously buffer overflowing. However, I would imagine restarting the Shifting Board would get it start working again (temporarily). So maybe it's only a problem on the tx buffer of the Main Board?

Any suggestiions would be greatly appreciated! I attached both projects in since it wouldn't let me upload two files.


Also: My tx is inverted because I'm switching 12V serial with an N-FET so don't mind that.

user_1377889's picture
9245 posts


There are two things I woud change in your program: I have learnt to never ever wait within an interrupt handler, be it directly or indirectly. Since you write out data to UART in your handler and that is a blocking call you will be waiting for all bytes stored away in the UART's FIFO. This cannot be accepted and will lead to some unpredictable behavour.

The second issue I see is: In your main-loop you write out 10 messages per second. Your interrupt will fire at any time, even within one of these messages and spoiling the sequence of the bytes to transmit.

I would suggest:

As you already defined, use a (volatile! as Dana suggested) variable that gets the actual state of the shift changed in your interrupt handler

In your main-loop:When you find it not being no_signal, setup the message, send it and reset the state back to no_signal, indicating the process has been finished.


Happy coding


user_14586677's picture
7646 posts

In the shifting project ISR should be set to rising edge -




You ISR in Shifting project calls another f(), readserial(). Generally speaking its best

to set a flag and service it in main. Heavy stack push would be avoided. Also variables

in an ISR should be declared volatile. Principal also applies to MainBoard project.






/* Style Definitions */
{mso-style-name:"Table Normal";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-fareast-font-family:"Times New Roman";
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}    Volatile


If you are driving a solenoid you generate large L based transients. You need to clamp

the coil as well as clamp the output of PSOC to insure you get no charge injection into

the substrate, which will do crazy unpredictable things in any CMOS part. Make sure for

solenoid diode it is a fast recovery diode, not a grunge power rectifier diode.




This circuit is pretty good example, but there should be diode clamps at the pin side

of the 1K connected to MOSFET gate to insure no miller coupling and parasitic C couples

transient back into PSOC output pin.




Regards, Dana

smbullet's picture
12 posts

 Thanks for the replies!


I tried switching the isr in the shiftig project to rising edge but that didn't make much of a difference. I haven't tried declaring anything volatile yet but that's next. I'm also driving the solenoids just as you mentioned.


How would you recommend writing UART on an interrut then? Just a flag? I can try that next. As mentioned above I'll also start using volatile.

smbullet's picture
12 posts

I tried both of your suggestions and neither of them worked. I also added LED's (Pin_1 to Pin_3) for testing and scoped the signal at the input. The signal looks perfect but the LED's are intermittent. Additionally, the shifting board hardly ever registers a shift when the LED's are lit. I have my revisions attached.

smbullet's picture
12 posts

 Woops, wrong file

user_1377889's picture
9245 posts

A new Creator update is out. I suggest you to do that update, there were some issues with components corrected.

I took the liberty to order and comment your program a bit.

You did not mention how the three switches are connected to the port, you are using a pull-up, so are the switches connected to GND permanently and open only when acted?

Am I right in: one switch for cludge

One switch for shift

one for the direction of the shift

Three for the elven-kings.... ah, no, wrong forum...





smbullet's picture
12 posts

 Haha, thanks for taking another look Bob. I'll check out your project once I finish updating. As far as the input goes, there are three input: up shift, down shift, and clutch. When you hit the clutch, it's just supposed to toggle the clutch solenoid. When you hit up shift or down shift, it is supposed to engage the clutch solenoid, wait for it to fully engage, engage either the up shift or down shift solenoid, wait, release the up or down shift solenoid, wait, then release the clutch solenoid. The waits are hardcoded as you can see in the shifting project. For testing purposes now, you can see I just have each button turn one of the solenoids on for 100ms then turn it back off.

Log in to post new comments.