uos.dupterm: Calling uos.dupterm() for the same UART twice disables the keyboard

[robert-hh]

V1.10.b1: Within _boot.py is dupterm() set for uart 0. If later dupterm is set for the same uart, keyboard entry is blocked. That seems to have cause many of the non-responding REPL complaints with v 1.10.b1, when this second os.dupterm() was still in boot.py. Obviously, that can be solved by deleting boot.py.

I raise that issue just to put it on the To-Do-List.

[jmarcelino]

Thanks for this report I had this problem at a workshop today and was going to look into it - your finding helps a lot!

[robert-hh]

It seems not to be limited to uart0 at the second dupterm call. It even happens, if first dupterm is disabled by calling dupterm(None), and then it is set again. Output still works.

[danicampora]

Hello guys,

On the latest release something is broken around UARTs initialization. I've already identified and fixed the problem. We'll release new firmware shortly.

Cheers,
Daniel

[robert-hh]

That seems to be fixed with version 1.10.1b1. Thus closing it.