conflict between D0/D1 and USB for M4 with CP 3.0

[jerryneedell]

This is more of a curiosity... I hope it makes sense.

Basic synopsis is that swapping the pins on a serial connection to an M4 running CP 3.0 causes the USB port to freeze and disconnect. Note that there is no UART support in CP3.0 at this time.

The full story:

I was trying out the new GPS library. It works fine in my Metro-M0 with CP 2.x. I mistakenly tried it on the Metro-M4 with CP 3.0 and of course found out that busio.UART is not yet implemented in 3.0 so not much to test...

However, I discovered that if I (mistakenly) connected the GPS TX to D1 and RX to D0 then my USB connection to the REPL would freeze and eventually disconnect. Sometime it took a few seconds (possibly waiting for a transmission)

For the Metro M0, D0 is configured as RX and D1 as TX - Connection the GPS to the M4 that way did not cause any problems with the USB connection.

Is this behavior expected. I realize it was a misconfiguration but it is not clear why it causes the USB connection to fail. Is this related to something in CP3.0 or is it related to the M4?

I was not able to replicate this problem using a USB to Serial cable- Neither pin orientation appeared to cause any problem.

I am using an "Ultimate GPS Breakout" - the USB connections are to /dev/ttyACM0 on a Linux box.

[tannewt]

Bumping this to Alpha milestone since it could be hardware related.

[jerryneedell]

FYI - verified that this issue is still present with current master.
Normally GPS RX goes to D1 (M4 TX) and GPS TX goes to D0 (M4 RX)
It now works great when I do this.
If I swap the wires, I am unable to use the connection to /dev/ttyACM0 - it may connect for a few seconds (but REPL does not work), then eventually won't even connect.

[dhalbert]

I was not able to reproduce this on my rev B M4 with the latest master. It works fine connected properly. If I switch the leads I just get "Waiting for fix...". I can go out of the REPL and re-enter, and I can hard-reset and then enter the REPL.

I am using the GPS Featherwing, powered by 3.3V and GND from the Metro M4. Are you using the GPS breakout with VIN and GND?

Using your supplied test program: gpstest.py.txt [rename to gpstest.py]

[jerryneedell]

I am using a breakout with VIN to Metro 3V , GND to GND.

With no code executing, but GPS VIN and GND Connected. I can reproduce the following:
Power off Metro M4 (all off)
Connect Metro D1 to GPS TX
Power ON (power to Metro M4 - also powers GPS)
Enter REPL via ttyACM0 - sometimes works for awhile (seconds to 10s of seconds)
REPL stops responding - eventually connection to ttyACM0 is dropped

I tried the same with D1 connect to 3V or to GND and had no problems.

[jerryneedell]

I wonder if this may be an issue with the GPS, not with the M4. Is it possible that abusing the GPS TX pin causes the GPS unit to draw excess current and is just dragging the 3.0 V line down causing the M4 to hang. I'll hook up a scope to it this afternoon and see if there is something happening on 3V.

[dhalbert]

The breakout (https://learn.adafruit.com/adafruit-ultimate-gps, right?) can take 5V on its VIN, so you could try powering it from the 5V pin. Is your USB power possibly wimpy? (Seems unlikely.)

The regulator on the breakout is low-dropout (310mv typical, 450mv max).

There is a level shifter on the GPS RX but not TX. Schematic: https://cdn-learn.adafruit.com/assets/assets/000/022/494/original/gpssch.png?1421536475

[jerryneedell]

Interesting - I tried powering the GPS via 5V and I was unable to reproduce the problem.
However, I have now gone back to 3V input and I also cannot reproduce the problem. Perhaps it was somehow due to the wiring on my breadboard. I have a lot of stuff connected.

Sorry if this has all been a red herring.

Since I can't reproduce it and since no one else has ever produced it and since it is only due to a miswiring in the first place, I think we can close this.

[dhalbert]

:-)