[SOLVED]Bug in the USART Harmony/FreeRTOS module
Platform: Curiosity PIC32MZ EF (100 pin) with 2 Clik board slots
WiFi4 Clik Board
MPLABX IDE v4.20
FreeRTOS v10.0.1 (the default version selected in MHC)
The WiFi4 uses a USART (Tx/Rx) interface to the PIC32MZ host. MHC configures the USART and a RESET signal to control the WiFi4 board. The USART driver uses an interrupt with byte-mode at a 115200 baud rate.
I used MHC to configure 2 COM ports with the USB CDC library -- COM1 is a console port to enter AT commands for the WiFi4 Clik board and COM2 is a log port to display logging messages created during run-time.
I developed a superloop app that talks to the WiFi4 board. All of the interfaces and features work as expected. The logic running under the superloop is a little complicated because it relies on multiple state machines and a lot of flags to implement a command/response element. [This is a standard interface characteristic in many serial interfaces, such as Modbus.]
An RTOS simplifies the implementation of the command/response element by including delays and waits for the back-and-forth communications, so I converted the superloop logic to use the FreeRTOS module included in the Harmony distro. It crashed. After many hours of checking configurations, debugging (sometimes) showed the PC was in the port_asm.S file (a FreeRTOS source file). No documentation on what that file does but it appears to deal with some interrupt vector locations.
I was able to isolate the "bug" to be in the Rx and Error callbacks defined in the USART driver (byte-mode). If I commented out the callbacks, the code did not crash (but it did not execute properly). These same callbacks worked correctly in the superloop version.
Conclusion: there appears to be a bug in the USART Harmony/FreeRTOS module.
post edited by BillP - 2019/03/04 08:50:27