[Bug] EV3 does not reply with correct version response in pybricks-code

[jaguilar]

Describe the bug
When flashing the EV3, as a first step, we ask for its version.

Currently, at least in some cases, the version response is just zeros. We should investigate why.

(As described here: #2375 (comment).)

[dlech]

Do we have more info on how to reproduce the bug? E.g. OS, USB host controller type, EV3 hardware revision, etc.

[jaguilar]

We know at least that it occurs on Windows with a USB 3.0 hub. In terms of the EV3 hardware revision: what's the best way to figure that out?

[laurensvalk]

On Ubuntu 22.04, the reply is mixed in with the command. Since the reply is longer, we could technically still get the version number.

get version command write b'\x00\x04\x00\x00\x00\x01\xf6'
REPLY TO GET VERSION:  b'\x04\x00\x00\x00\x01\xf6\x7f\xb6\x00\x00\x00\x06\x00\x00'
                            ^
                             bad size

Note that this has always been the case, for both pybricksdev and Pybricks Code. The issue I opened for Pybricks Code has the screenshot of the corresponding error, which maps to these same numbers.

This is the case for all three EV3 revisions. You can tell them apart from the small embossed letters on the back, near the certification marks:

• (blank): 2013
• EV3: 2015
• EV3 P-Brick: 2017

But this is also what makes the version command a bit pointless. There are three versions, but they all return 6.

[jaguilar]

FWIW, in my same change where I was logging the HID interactions, I didn't see any data in the reply even if I used the forced length trick that we use in pybricksdev. Perhaps I misunderstood something but, yea.

[jaguilar]

This one says ev3 p-brick, so I guess I have a 2017 one here.

[laurensvalk]

Right, it sounds like it could be a bug in the EV3 bootloader that's timing sensitive. So far though, I haven't been able to see it work once, but it must be working on @dlech's system 😄

Even when it does work, it does not return a distinguishable version number, so I don't know that it's worth keeping this in the code.

While this one is not critical, there is one other reply we suppress in Pybricksdev also. I don't have access to the code right now, but I think it was the final message. Maybe this was related to a bad firmware size like @jaguilar found, but it's worth keeping an eye on.

[jaguilar]

I'll leave it up to you guys whether it should be kept in the code. For now I think making it fault tolerant and documenting the cause is the best compromise. :)

[dlech]

OK, so this the same old known issue with USB 3.0 and EV3 that we've seen before: c4ev3/ev3duder#34

REPLY TO GET VERSION: b'\x04\x00\x00\x00\x01\xf6\x7f\xb6\x00\x00\x00\x06\x00\x00'

In the before_fixes_filtered_corrected.pcap packet capture from @jaguilar the 0x06 isn't there:

So I think the best action would be to remove this check from both Pybricks Code and Pybrickdev.

In the same packet capture though, we also see this echoed packet phenomenon on the last 0xf2 command reply. So the problem seems a bit deeper than just on the version command.

So both Pybricks Code and pybricksdev should be modified so that the reply handler can handle this for all replies.