The S32K LPUART receive interrupt function does not trigger the problem

cancel
Showing results for 
Search instead for 
Did you mean: 

The S32K LPUART receive interrupt function does not trigger the problem

273 Views
Yi_Feng
Contributor I

Hi

In S32K, I set CTRL volatile Uint32_t 2883584 of LPUART1 (receive enable, send enable, and receive interrupt), but in the actual debugging process, I found that LPUART1_RxTx_IRQHandler was not frequently triggered when sending serial port data to S32K, and the RDRF identification in STAT volatile Uint32_t 1087897600 was not set to 1.What is certain here is that the actual physical data sent to S32K is connected to the relevant pins of S32K, but this problem of sometimes triggering and sometimes not triggering the receiving interrupt function does not know how to solve, I hereby ask for help.

 

Thank you very much

Yi_Feng

0 Kudos
3 Replies

264 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi Yi_Feng,

Can you share the project so that I can test it?

The RDRF flag assertion depends on RXWATER as well.

Did you use the correct baud rate?

Do you see any error flags?

 

Thanks,

BR, Daniel

 

0 Kudos

243 Views
Yi_Feng
Contributor I

Hi BR, Daniel,
Thank you for your answer. I have carefully read your reply. Baud rate must be correct.
RDRF identification depends on RXWATER. Currently, RXWATER is the default in my program. You can check this value through the program test in the attachment, or how should I configure it correctly?
I put the project in the attachment, the test project contains the last time I was in the can get the corresponding test phenomenon, please allow me to describe the requirements, I need in this project I need to use a serial port for full-duplex communication, such as the project UART1 for uncertain interval, such as 10 ms and 20 ms (example program is 50 or 500 ms ms) to send data out, use UART1 receiving interrupt receiving treatment may receive data at any time, the register configuration for LPUART1 - & gt;CTRL=0x2C0000, what is puzzling is that everything was normal when the program was just running. The normal 50ms of UART1 was sending 69 bytes of data out all the time, and the PC sent more than 10 bytes of data to UART1 at the interval of 10MS. S32K could normally receive data from UART1 and forward the received data through UART2.
But After the program has been executed for some time,
Void LPUART1_RxTx_IRQHandler(void) does not trigger, but the actual data is always sent to UART1 of S32K. After the break point, check LPUART1->The bit 21 identifier of the STAT register is always 0, but the UART1 50ms interval sent data is normal at this point, but it cannot be received. At this time, the reset program can run normally for a period of time after re-execution.I have added some auxiliary code to the program to test if there is any change in the register configuration of UART1 during the execution of the program, but as far as My tests are concerned, There is no problem there.
This question is very important and very disturbing to me. Could you or your team help me to solve the problem? The test project is in the attachment
Thank you very much!
Yi_Feng

0 Kudos

229 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi Yi_Feng,

Since it was working correctly for while, the configuration is correct.

And you don't use the RX FIFO (disabled in your project), therefore RXWATER is not used and the buffer depth is 1.

You could lose some data because of another interrupt which would lead to an overrun.

Can you enable error interrupts as well, especially START[OR], CTRL[ORIE].

 

Could you try using the highest priority level for the LPUART1 interrupt.

I have noticed that the interrupt priorities in you project are set incorrectly.

S32_NVIC->IP[LPUART1_RxTx_IRQn] = 0x7; // Not correct

S32_NVIC->IP[LPUART1_RxTx_IRQn] = 0x70; // Corect

It should be written to the 4 MSB of the IP bit fields.

 

Reading the DATA register clear the RDRF flag.

And the DATA register can be read by the debugger in Memory view or in the Register view as well not only by the core. Please close it during debugging.

 

Regards,

Daniel

0 Kudos