I'm trying to solve an intermittent problem when using the nRF51422 UART with CMSIS-RTOS (RTX) and MDK Networking library (V6.2) (TCP/IP stack).
My questions relate to event/timer handling, correct use of the rtos_suspend variable and the like. I hope this might be useful to others having difficulty with RTX.
Brief application details
Using RTX configuration for nRF51 family - RTC1 provides the tick timer. No Soft Device in use. nRF51 UART connected to modem (RS232). Own hardware.
I've written a CMSIS compatible USART driver adding GPRS Modem and null modem support.
nRF51 establishes a PPP connection via the modem then uses http get/post requests etc to a cloud based server using BSD Sockets interface. Frequency is several requests every few minutes.
Two RTX threads for the comms - one runs net_main() and the other handles client activity.
The client thread brings up the PPP connection when needed (when new data arrive on the nRF51's SPI slave port), POSTs the new data, receives the HTTP OK response, then drops the connection (after a delay) if no longer required.
Additional timer thread is running which is required by RTX and the networking library.
Problem details
I think the CMSIS-USART driver is working fine but there may be some problems remaining.
The application works fine for several hours at a time but then the client thread hangs - apparently always in osSignalWait() (from either BSD sockets recv() or send()). With only one UART on the nRF51422 I can't use the debugging build of the MDK networking library.
I'm assuming the net_main() loop is responsible for maintaining the PPP link and for exchanging all receive / transmit IP data between my UART driver and the client thread via sockets, or alternatively signalling the open socket that a timeout or other underlying network error has occurred.
The PPP link is at some point being terminated, but the client thread remains stuck waiting for a signal, never returning to my application so that I can deal with the error. My modem driver is also not being notified that 'NO CARRIER' has been received, although this and the preceding LCP termination and response frames are clearly in transmit and receive buffers as the last exchange of data before the hang occurs.
Although this may turn out to be a networking library problem (I have also raised this with Keil tech support) it looks like something is going wrong with the signalling mechanism so I wondered if this might be associated with the nRF51 implementation of RTX and use of rtos_suspend variable?
Having seen the note about limitations of use of RTX in the S110 data, I've already set the global rtos_suspend variable to zero in my UART ISR (since this posts events to RTX) and also in the callback functions from the Nordic spi_slave.c driver file (which are called from ISR context). These don't seem to have prevented the problem occurring.
I have also tried setting rtos_suspend to zero (instead of 1) in RTX_Conf_CM.c. This seemed to improve things considerably but has not eliminated the problem and may just be a coincidence.
It is not immediately obvious where else this might be causing problems so I would appreciate any suggestions of where to look next.
Is there another CMSIS compatible USART driver available that I could try?
Is this requirement (for setting rtos_suspend to 0) a limitation of using any code libraries (such as MDK middleware) using RTX which are not built specifically for Nordic parts? I note there are some recent comments on mbed.org about other difficulties using RTX.