Thonny lockup using ESP8266 Mini UART

[Comalco]

Folks,

I have been working through learning Micropython and using several versions of the ESP8266 Mini and RPIPico to do so..
So far, I have played with DS3231, AT24C32, HCSR04, WiFi, various OLED and LCD displays, buttons, leds, etc.... learning lots along the way and I have been helped by some great answers from more experienced people here on this board..

I started playing with a HC05 module and the Bluetooth Serial App examples on various websites and YouTubes. I have experienced a problem which I think was being discussed on the Micropython forum earlier this year. When I add a single UART.write command to send the current RTC time to the HC05 the code works fine... no problem, it can run in a loop all night without issue. But the moment I run the code from Thonny, Thonny itself then will not respond to a stop/reset, CtrlC etc and I cannot interrupt the running code. I get a "wait for the code to finish or press Stop/Reset or CtrlC" message, but no matter what I press, or how many times I do it, I can never break in and stop the code.

I have found I have to do a firmware reflash to reburn micropython to the module (which works ok from Thonny), reload all my libraries and main.py and start all over again. I have tried it repeatedly, using 2 styles of ESP8266 Mini, and they both do exactly the same thing.....

Reading the following thread and doing a bit of Googling suggests others have seen this manifested through various mechanisms (print, uart, etc) and it appears to occur on various hardware platforms.

Locked out of Pico after main runs?

It seems the belief is that its a timing issue with the USB port initalising properly versus starting code executing. Is the recommended fix for this issue (i.e. a line of code, a sleep(xx), or ??? Or do I just put a long sleep(xx) delay in my code as one of the comments in the above blog suggests works ok ??

I am using the latest ver 1.19 of micropython. In my case a "uart = UART(0,9600)" line triggers the problem, as whether I include an actual uart.write instruction later in the code, or not, doesnt matter once the uart config statement is there.

from machine import Pin, SoftI2C, PWM, ADC, RTC, UART
..
..
..
uart = UART(0,9600)
..
..
..
uart.write(time_str)

I have done fair level of Googling and have been unable to come up with anything better than the above micropython forum link to find it being discussed.

I think the issue is covered here; https://docs.micropython.org/en/latest/esp8266/quickref.html?highlight=dht at the end of the UART section, and the .dupterm command is described. Considering it is the UART config line that seems to trigger the problem, how can the .dupterm command be used to prevent the problem? Or is there another preventative/fix? Thanks.

[robert-hh]

You mentioned ESP8266 and RPiPico, but did not say which board causes the trouble. Let me guess it's the ESP8266. This chip has only one UART, which is used by IDEs like Thonny or terminal emulators for communication. If you use it for the HC05, it will be re-configured and Thonny or any other terminal emulator cannot use it any more. With the RPiPico this should not be the problem, because there USB is primarily used for REPL and the UART devices are independent.
For the ESP8266, yuo can as well switch the console using a Web Interface, called WebREPL. Then the single UART free for other tasks. WebREPL usses a browser as Terminal. I do not know if Thonny supports it.
dupterm is then used to detach the REPL channel from UART and attach it to the WebREPL stream. dupterm may also be used e.g. with RPiPico to duplicate (or detach) the console data stream to a UART.

[Comalco]

Thanks Robert.
Even as a newbie everything you wrote makes sense for me.
It is the ESP8266 that is the problem board. I stopped using RPI because I got attracted by the power vs cost of the ESPs.
So my "learning" code is now aimed at the ESP and I put the RPIs in a drawer for another project on another day.
Thanks for your comments. Much appreciated. I will investigate the WebREPL and any other options instead of Thonny if that isnt supported. Its all a good learning curve for me to explore.

[Fre19]

I used the (Wemos Di) ESP12's UART to communicate with the RPico and learned that by using dupterm, the ESP buffer is reduced to 16 characters only. Therefore I rewrote my comms routine to split up te comm between ESP12 and Rpi in chunks of 14bytes+a terminator character (LF chr-10). It works like a charm and I do not notice any latency. All the comm I do for MQTT, IFTTT goes via this splitup and it works like a charm.