SPWF04SA - UART_IRQHandler issue

[damien_lobb]

Hello,

I am developing a program with a WiFi socket user interface. I can communicate with the module using the Socket Test App. I give a certain command and my MCU does something. I generally found this to work fine until it came back after running certain functions. Initially it seemed to me like the UART interrupt just kept firing over and over again, and wouldn't continue as it should, so I stopped it running any functions after receiving commands, but it still occurs.

I now realize that what is really happening is the HAL_UART_IRQHandler isn't acting like it does earlier in the program. When the client sends it data, the callback function echos it back to the client. When this happens the program hits the break point shown in the screenshot (UART_EndTransmit_IT). However when the program fails it is because it doesn't reach this breakpoint.

So my question is about the flags the if statement above references, USART_CR1_TCIE and USART_SR_TC.

if(((isrflags & USART_SR_TC) != RESET) && ((cr1its & USART_CR1_TCIE) != RESET))

What does this line actually mean?

Do the two interrupt flags change from hardware, or are they changed in code somewhere?

And of course, any thoughts on how I can fix this issue?

Thanks

[damien_lobb]

Here is it in action again, The first time around it prints all four messages to the client ("Select Mode", etc). Once it exits the functions it has completed, it basically starts again, but when it tries to print those four lines, it does the first one, the third one twice, and then gets caught in the HAL_UART_IRQHandler.

[damien_lobb]

Had a thought about what might be happening.

I have one function where I print all the filenames on an SD card. There are roughly 15-20 file on the card, and it never prints all of them, sometimes it will print 10, sometimes 1, and everything in between. It seems that the HAL_UART_IRQHandler never hits "UART_EndTransmit_IT", as it doesn't receive a response from the AT Command in the function USART_Receive_AT_Resp();

I am thinking this may be because at some point during printing these messages to the client, the module gives a +WIND message, and therefore doesn't give an AT response (Something I noticed when playing around with the VCOM example).

Is this likely to be the case? If so, how can that be handled?