Interesting UART problem

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
Post Reply
Posts: 167
Joined: Mon Oct 05, 2015 12:24 pm

Interesting UART problem

Post by danielm » Mon Oct 03, 2016 1:05 pm

I am developing a device with CC3200 MCU running WiPy port of MP. My intention was to use both UART interfaces:
- UART0 for logs through serial console and REPL
- UART1 for communication with another device through MAX232

I am experiencing very strange behaviour:
When receiving data through UART1 sometimes these data are mixed with serial console output. In some cases I can clearly see several characters from serial console output to make their way into data read from UART1 interface. I was thinking that there must be some interference problem in my HW despite the fact I did not find and short circuits - RX/TX pins of UART0 and UART1 seems to be isolated from each other. I decided not to init UART0 and not to call dupterm() at all.
I connected to the console output/REPL through Telnet and I observed similar behaviour - console output characters making their way into received data of UART1.

My question is: is there any place in SW stack of MP and underlying layers (or in the HW) where these data streams could mix? Maybe there is some shared buffer?

- I am using CC3200 module similar to this one (not the original WiPy): ... 76696.html
- I am reading data from UART1 by checking machine.UART.any() and performing when necessary within the main loop (while based) - I did not try how it would behave in case of reading through an ISR yet

User avatar
Posts: 2228
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Interesting UART problem

Post by Roberthh » Tue Oct 04, 2016 5:22 am

Hello danielm, I can confirm a similiar observation on WiPy, but have no cure. When I observed that, i just gave up usuing UART. At least I tried to reduce the impedance on the UART lines, sorting out some crosstalk on the wires. Since you are using a different hardware, it is more likely a software problem.

Posts: 167
Joined: Mon Oct 05, 2015 12:24 pm

Re: Interesting UART problem

Post by danielm » Tue Oct 04, 2016 8:23 am

Robert, I also believe that it is a software problem. It happens with UART0 not initialized and also with different baud rates of UART1 - I tried with 115200 and 1200 and symbols from console/REPL made it to received data of UART1:

[2016-10-03 16:07:23] (COM2) Received from external unit: SET_OPSTATUS_FORCED_IDLE
[2016-10-03 16:07:23] Seting EEV to 0
[2016-10-03 16:07:24] EEV set to 0
[2016-10-03 16:07:24] Changing operational status to FORCED-IDLE ()
[2016-10-03 16:07:24] (COM2) Sent to external unit: OPSTATUS_FORCED_IDLE_SET
[2016-10-03 16:07:27] (COM2) Received from external unit: \x001\x00\x00\x005\x00\x00\x00\xaf\x00\x00\x00\x01\x00\x00_OILCYCLE
[2016-10-03 16:07:27] WARNING - Unknown request
[2016-10-03 16:07:27] (COM2) Sent to external unit: UNKNOWN_REQUEST
[2016-10-03 16:07:28] (COM2) Received from external unit: SET_OPSTATUS_PRE_OILCYCLE
[2016-10-03 16:07:28] Changing operational status to PRE-OILCYCLE ()
[2016-10-03 16:07:29] (COM2) Sent to external unit: OPSTATUS_PRE_OILCYCLE_SET
[2016-10-03 16:07:29] Seting EEV to 500
[2016-10-03 16:07:30] EEV set to 500
[2016-10-03 16:07:30] Changing operational status to OILCYCLE ()
[2016-10-03 16:10:29] (COM2) Sent to external unit: OILCYCLE_FINISHED
[2016-10-03 16:10:30] (COM2) Received from external unit: OILCYCLE_FINISHED_ACK
[2016-10-03 16:10:30] External unit acknowledged finished Oil cycle
[2016-10-03 16:10:30] Changing operational status to POST-OILCYCLE (OC Timer:181s)
[2016-10-03 16:10:31] (COM2) Received from external unit: SET_OPSTATUS_IDLE
[2016-10-03 16:10:31] Seting EEV to 160
[2016-10-03 16:10:32] EEV set to 160
[2016-10-03 16:10:32] Changing operational status to IDLE ()
[2016-10-03 16:10:32] (COM2) Sent to external unit: OPSTATUS_IDLE_SET
[2016-10-03 16:10:33] (COM2) Received from external unit: CStaT:21P_NOTIF
[2016-10-03 16:10:33] WARNING - Unknown request
[2016-10-03 16:10:33] (COM2) Sent to external unit: UNKNOWN_REQUEST
[2016-10-03 16:10:35] (COM2) Received from external unit: COMP_STOP_NOTIF
[2016-10-03 16:10:35] Compressor stopped (CStoT reset)
[2016-10-03 16:10:35] (COM2) Sent to external unit: COMP_STOP_ACK
IDLE Rhm:51% Ta:24°C Tkd:25°C Tv:24°C Tk:26°C Foto:87 EEV:160 Fan:106RPM SuT:1822s CStaT:290s CStoT:69s

Could you please provide more details regarding your test setup with WiPy and then I will create an Issue on GitHub.

Posts: 167
Joined: Mon Oct 05, 2015 12:24 pm

Re: Interesting UART problem

Post by danielm » Thu Oct 06, 2016 7:29 am

Reading UART data to bytearray through ISR did help. It is easier when messages are up to 8 bytes long.

Anyway I think there must be some memory leak. When not printing anything and reading UART within main loop, received data are often mixed with some other data.

Post Reply