It seems that if you look at the Kinetis' UART's registers in MCUXpresso, following UART receive operations no longer work. I can see data going out from the Kinetis and being replied to by the peripheral device on my oscilloscope but it is not registering at all in the hardware registers of the Kinetis' UART.
I've been going crazy trying to debug a problem I'm having with the FreeRTOS UART drivers not handling the changing of the UART's baud rate during operation and I've been trying to deal with the application not receiving in cases which normally worked until I figured out that by looking at the UART registers in MCUXpresso I was changing the operation of the UART - hence the subject title. I have observed this problem with both the Bare Metal and FreeFRTOS SDK drivers for Kinetis parts running under MCUXpresso using the Segger J-Link Plus. YMMV
My transmit code consists of using the FreeRTOS UART API followed by timed waiting for a notify by the receiving task when a correct packet has been received. I use the timeout to determine what to do next if the packet is not received:
notifyValue = 0; timeOut = appropriateForTXStringCommand;
if (0 != (error = UART_RTOS_Send(&handle
, (uint8_t*)TXString
, sizeof(TXString) - 1)) {
PRINTF("\rUART Send Error - %i"
, error);
vTaskSuspend(NULL);
}
xTaskNotifyWait(0x00
, 0xFFFFFFFF
, ¬ifyValue
, timeOut);
if (!notifyValue) {
PRINTF("\rNo Response for UART Send"
}
In the receiving task, I'm waiting for a single character to be received using the FreeRTOS UART API and when a complete & correct packet has been received then I notify the sending task.
for (;;) {
if (kStatus_Success != (error = UART_RTOS_Receive(&handle
, &recvChar
, sizeof(recvChar)
, &n))) {
PRINTF("\rUART Hardware Error - %i"
, error);
vTaskSuspend(NULL);
}
else {
// Add character to packet
if (packetCompleteAndCorrect) {
// Process Packet
xTaskNotify(uartSender_taskHandle // Notify Sending task Packet Received
, UART_RX_COMPLETE
, eSetBits);
}
}
}
I've listed the code to explain that I'm now only checking the UART registers ONCE each test run to see what's happening in the UART at that particular point in the code and then halting the application and restarting it.
So, in the example above, I run my tests two times, the first with a break point at the "UART_RTOS_Send" method call before which I look at and record the UART register values and the second time at the "if (!notifyValue) {" statement to see what the register values are (and whether or not they were received by looking at "notifyValue").
I hope this is the correct way to let people know about this issue - I did search on what I'm seeing here before posting and it doesn't seem like anybody has had this issue. I suspect that the problem comes from reading certain of the UART's registers and fixing the problem would end up being more trouble than it's worth, which is why I wouldn't log this as a bug, but an issue to be aware of and work with using multiple debug runs with breakpoints before and after each transmit/receive.
