I try to use UART Communication together with an RS-485 IC (SN65HVD72DGKR).
Sending Text to an PC work correctly.
But I'm not able to receive some Text from the PC.
I checked out the lpuart example and also this topic in community: S32k uart RX interrupt handler problem
But the callback function never gets called.
Even if I take out the RS485 Transceiver and connect RX and TX to a loopback, the Callback never gets called.
I use LPUART component from Processor Expert (see attached project).
What could be wrong here?
Thanky for any hints.
Could you, please try again the example lpuart_echo_S32K148?
This example expects LF at the end of the message.
I tested it on the S32K148EVB:
I hope it helps.
I imported the lpuart_echo_S32K148 example and changed the IOs to for my board. I also changed the clock settings according to my prototype board (Same settings as the attached project from the original question).
I could noticed, that the function LPUART_DRV_SendDataBlocking() doesn't work for me.
In my previous tests I used a function from ADC example where the function LPUART_DRV_SendData() is used.
So I did not receive any data on the PC with this sample programm. The programm also run in the part where the it will exit and stop:
I attached you the adjusted sample project. Maybe you find a mistake there?
I have tested both your projects. Do you use your own bord?
With lpuart_echo_s32k148_2.zip I'm able to receive and transmit data without any issue.
With Test_UART.zip I'm able to get into rxCallback with code used from example mentioned above (just for test if it is working)
Thanks for your feedback.
Yes I use a prototype board with an S32K148_144 on it. From this point of view it should work as well.
As mentioned in the original question, I try to use UART Communication together with an RS-485 IC (SN65HVD72DGKR).
I think this should not influence the sending process. I don't have any idea why the function LPUART_DRV_SendDataBlocking() doesn't work for me. Do you have any hint what can be checked?
Could you, please, check the SDK version?
The newest one is 3.0.2. However, there is a new S32 Design Studio for ARM version 2.2 (you can try it).
I hope it helps.
I have checked the release notes of version 3.0.1 and 3.0.2 and I have not seen changes regarding UART.
However, I just want to be sure, that you have the newest version.
Have you tried it?
Version 3.0.2 should be installed.
In the menu "Help - Install new Software" there are no more updates available.
But I can't choose SDK 3.0.2 if I want to create a new project.
Is it then updated correctly anyway?
However, after the update, the see the same errors as described in the previous messages:
- Callback doesn^t get called
- LPUART_DRV_SendDataBlocking() doesn't work for me
The SDK 3.0.2 is a patch for 3.0.0.
So, it should be installed correctly.
I have discussed your issue with an application engineer and his advice is to check the signals before that transceiver which can alternate signals.
I changed the test setup. Therefore no more transceiver is involded.
But also with this I have still the same problem that the Callback never get called.
I found another thread where someone has the same problem (s32k144 UART Callback )
The solution nearly worked also for me.
I attached the adjusted sample programm. There is a file with the code that worked for me.
It is strange that I always have to call LPUART_DRV_ReceiveData after sending some data, that I'm able to receive some data.
Makes this sense for you?
Hi Mario. Yes, you have to call LPUART_DRV_ReceiveData constantly when receiving a new frame. This is how the SDK is designed. An alternate way is to call the set RX buffer function in the receive callback function.
Sorry for my late answer. At the moment our debugger is not working and we are waiting for a new one.
According to your advise:
I wrote in the original question the following remark:
"Even if I take out the RS485 Transceiver and connect RX and TX to a loopback, the Callback never gets called."
So I do not think that the transceiver is the problem here.
But as soon I get the new debugger, I will test this again.
Thanks for your patience :-)