[Bug] DCMotor does not function with CityHub in PortA after no device attached warning

[s-drahcir]

Describe the bug
DCMotor (in my case train motor) does not work with CityHub when plugged in to Port A AFTER warning regarding no device attached/detected etc (OSError: [Errno 19] ENODEV)

To reproduce
Use https://beta.pybricks.com/ v3.1 with CityHub and train motor. CityHub reports: ('cityhub', '3.1.0b1', 'v3.1.0b1 on 2021-09-21').

1. In beta.pybricks.com, use the example "Making a train drive forever".
2. With no DCMotor attached, run example. At this point, the script will stop and the console will show:

Traceback (most recent call last):
File "main.py", line 7, in
OSError: [Errno 19] ENODEV:

A sensor or motor is not connected to the specified port:
--> Check the cables to each motor and sensor.
--> Check the port settings in your script.
--> Check the line in your script that matches
the line number given in the 'Traceback' above.

ValueError: incompatible .mpy file

4. Plug DCMotor into Port A.
5. Run the script again. At this point, the script runs with no errors on the console until it is stopped. However, the DCMotor does nothing.

Expected behavior
For it to work :)

Notes
It's possible it is not just limited to DCMotor. However, as this is the only device I have, that's all I can confirm.
Does not appear to have the same issue with Port B when specified in the script. It will warn, but plugging DCMotor into Port B and then running the script again works fine.

[laurensvalk]

Thank you for reporting this. I can reproduce this on my end as well. We will investigate.

In the mean time, things should work if you plug in the motor before you turn the hub on.

[laurensvalk]

This happens on both ports.

When we fix this, we should also fix the following:

• Turn off the port when a passive device is removed. Right now, the motor keeps turning if you plug it back in.
• Make sure the DCMotor class gives the right exception when using it with a motor with encoders.

[laurensvalk]

Does this happen consistently for you, @s-drahcir ?

I can't seem to reproduce it today, so I'm wondering if I saw something different two days ago.

[s-drahcir]

Does this happen consistently for you, @s-drahcir ?

I can't seem to reproduce it today, so I'm wondering if I saw something different two days ago.

Apologies for not replying as I've been away.

I have tried again and still experience the same issue.

This is again using https://beta.pybricks.com/ and 'cityhub', '3.1.0b1', 'v3.1.0b1 on 2021-09-21'. As a side note, I did both "Check for update" and reflashed the PyBricks beta firmware to confirm I was using the latest available.

[laurensvalk]

Something like this is also happening on port C of the Technic Hub.

Time for a closer look!

[laurensvalk]

It appears that passive devices are sometimes detected as UART devices.

This is also happening on Prime Hub, which make it a bit easier to debug.

Also, a passive device can be detected as the wrong type. Such as 9 for a train motor instead of 2. Or 8 for a Wedo 2.0 motor instead of 1. (ID 2 detected as DEV_ID_GROUP_PULL_DOWN instead of DEV_ID_GROUP_GND)

So maybe this is the same issue, getting pbdrv_gpio_input(&pdata.uart_rx) wrong.

[laurensvalk]

It appears that passive devices are sometimes detected as UART devices.

It would also be good to make sure we can get unstuck higher up --- uartdev.c isn't supposed to keep trying to sync a bad device.

[laurensvalk]

I removed my assignment, so feel free to pick this up if you want to, @dlech.

The tl;dr to reproduce:

• Build latest master, turn on debug prints in ioport.
• Connect to the Prime Hub with Pybricks Code.
• Plug in a DC Motor repeatedly until it erroneously says that it sees a UART sensor.

Sometimes it takes a while, sometimes it happens right away.

To be complete, this can go wrong as well:

Also, a passive device can be detected as the wrong type. Such as 9 for a train motor instead of 2. Or 8 for a Wedo 2.0 motor instead of 1. (ID 2 detected as DEV_ID_GROUP_PULL_DOWN instead of DEV_ID_GROUP_GND)

So maybe this is the same issue, getting pbdrv_gpio_input(&pdata.uart_rx) wrong.

[dlech]

This should be fixed now. With the debug prints, I occasionally see this when a medium motor is first plugged in:

ioport(B): Type changed from 0 to 8.
ioport(B): Passive device detected.
ioport(B): Type changed from 8 to 1.
ioport(B): Passive device detected.

But since it immediately transitions to the correct device ID, I don't think this should be a problem.

If the problem still persists, Adding more calls to PT_YIELD(pt); to increase the delay (2 ms per call) to https://github.com/pybricks/pybricks-micropython/blob/aa5712fd44e67f9b00a471c5ee8158896b2a53bc/lib/pbio/drv/ioport/ioport_lpf2.c#L360 could do the trick too.