CY8CKIT-145 PSoc4-40XX UART RX interrupt is not working

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

cross mob
lock attach
Attachments are accessible only for community members.
dudeskie
Level 1
Level 1
First like given First reply posted First question asked

Hi,


A pleasant day to you all!

I humbly request for a technical support from this community regarding my cuurent predicament. Attached herewith is my simple implementation of an instrumentation project, using the CY8CKIT-145-40XX PSoC 4 module. It involves voltage measurement (using PSoC4 ADC block) and serial communication. The master controller is a PLC, with RS485 connection. My CY8CKIT-145-40XX is connected to a TTL-to-RS485 converter. This is just a single node point-to-point communication. The sequence is as follows:

1.) PSoc4 will send an initial command string to the PLC (e.g. "ABCD\r"). In return, the PLC will turn on and turn off some relays. After the relay actions, the PLC will send back some string to PSoC4, in which the PSoC4 will send back the acquired readings to the PLC, as a result.

2.) Initially, I used the baud rate of 9600 bps, but I intentionally set it to the lowest acceptable baud rate of the PLC of 1200 bps. This is due to the fact that I am yet currently finding the cause of the miscommunication, and at the same time, I have just a digital multimeter for various signal tracing and measurements.

3.) I implemented the UART block, with RX interrupt. First, with external interrupt to no avail. Lately, I switched to internal interrupt, but the result is the same. The PLC promptly receives the string command coming from PSoC4, and the PLC sends back the command. This is where it is getting weird.

4.) The CY8CKIT-145-40XX cannot be triggered by the incoming serial data from the PLC. But, a voltage disturbance is observed on the kit's pins (P3.0 as RX, P3.1 as TX). This validates that the PLC is indeed sending serial data. However, I observed that the interrupt service routine/handler is somewhat triggered by the transmit action only, and not by the PLC. Whenever the PSoC4 sends out the string, the interrupt is triggered altogether. So, I know that the interrupt handler is working as expected, albeit the RX interrupt from the PLC is not received properly.

5.) I referred to similar problems in this community, but my situation is quite different. And honestly, I even tried some recommendations on some threads (regarding PSoC4 UART RX) to my project, but the result is still the same, RX interrupt cannot be triggered by the PLC. In the past, I have used PSoC5LP and PSoC4 using I2C, and not UART, with no problems at all.

Please find time to check on what I am doing is wrong, or lacking. Your most prompt and positive response will be highly appreciated.


Thanks and Best Regards,

dudeskie

0 Likes
1 Solution
BiBi_1928986
Level 7
Level 7
First comment on blog 500 replies posted 250 replies posted

Hello.

I had a very quick look at the text files (I can't open projects in Creator 4.4).

In "main", move CyGlobalIntEnable ahead of sending UART characters.

In ISR, don't clear RX Int status flags unless you actually serviced the RX char.  Move the clearing statement into the RX Int "if" statement where you check for "empty".

Given this is a 485 interface, check that you haven't reversed the +/- signal wires.
And, check that the voltage levels are correct between the PSoC and TTL/485 convertor.  On KIT-145, PSoC is powered from 5V.  If TTL/485 is powered from 3.3V, it might not have compatible voltage levels for PSoC.

You might want to review this excellent article from Motoo on serial com with PSoC.
https://community.infineon.com/t5/Code-Examples/MCU-Tester-a-Swiss-Army-Knife-for-PSoC-CY8CKIT-059-v...

 

View solution in original post

3 Replies
BiBi_1928986
Level 7
Level 7
First comment on blog 500 replies posted 250 replies posted

Hello.

I had a very quick look at the text files (I can't open projects in Creator 4.4).

In "main", move CyGlobalIntEnable ahead of sending UART characters.

In ISR, don't clear RX Int status flags unless you actually serviced the RX char.  Move the clearing statement into the RX Int "if" statement where you check for "empty".

Given this is a 485 interface, check that you haven't reversed the +/- signal wires.
And, check that the voltage levels are correct between the PSoC and TTL/485 convertor.  On KIT-145, PSoC is powered from 5V.  If TTL/485 is powered from 3.3V, it might not have compatible voltage levels for PSoC.

You might want to review this excellent article from Motoo on serial com with PSoC.
https://community.infineon.com/t5/Code-Examples/MCU-Tester-a-Swiss-Army-Knife-for-PSoC-CY8CKIT-059-v...

 

Hi BiBi_1928986,

 

A pleasant day to you!

The situation is still the same, irregardless of the insights from the link you have provided. You, however, provided me some enlightenment regarding the clearing of flags. As I mentioned in my question, I have no access to oscilloscope, only a DMM in my disposal. As with other questions in this forum, I tried to source out an extra USB-to-TTL converter, to validate the signals if indeed the PSoC UART block receives the proper signal. Voila! The CY8CKIT-145-40XX was eventually triggered upon sending a dummy serial data. The embedded solution that I am currently working on is now resolved!!! The RS485-to-TTL module is the culprit. The RE and DE signals should be complementary at all times, and should be controlled by an external stimulus when sending serial data. During sending, both DE and RE should be high. During receiving, both DE and RE should be low. What I did on my circuit was that DE was permanently tied to HIGH and RE was permanently tied to LOW. With this configuration, whatever data is present on the DI pin of the MAX485 was also present on the RO pin of the MAX485, which gives off the false reception condition of the PSoC.. In my circuit, I tied them to P4.3, and presto!!! The communication is flowing like a breeze. I'm currently linking the PSoC4 and PLC at 115200 bps, with no glitch at all!!! Thank you for the inputs, the prompt and positive response. A receptive community indeed!!

 

Thanks and Best Regards,

dudeskie

0 Likes

Good to hear you got it working.

Yes, those 485 transceivers can be a handful.  But once you get them sorted out, wow, look at the distances you can send data.