There have been a subset of Huawei mobile devices that we’ve encountered that will not enumerate when connected to our devices (using kl26z mcu). We spent quite a bit of time debugging the issue. In a nutshell, it seems like the device doesn’t appear to recognize that it’s attached to the bus. We also tested the problematic devices with the FRDM-KL26Z eval board and observed the same problematic behavior. We reached out to Huawei, but we haven’t received a response. Has anyone experienced any issues of this nature?
We’ve observed that a there are USB bus issues when communicating with several of the “lite” devices. The devices appear to have difficulty correctly interpreting the bus state. The USB controller in our sensor (host side) detects the Huawei (device side) attach and there is no high-speed. This is also how it’s interpreted by the USB analyzer. Our device proceeds with attempting full speed comms and it fails. Please see screen shot below.
The behavior that we’d expect is for the high-speed device to attempt negotiation to high-speed after the attach and subsequent bus reset. At which point our host would not indicate high-speed support, reset the bus and then proceed to communicate at full-speed. This is the sequence that occurs for other devices, including most Huawei phones. See an example of this below.
We are currently using the full speed controller integrated into the NXP(Freescale) MKL26 MCU. We observed the same behavior when attempting to communicate with the problematic devices from the NXP FRDM-KL26Z development board.
The problematic “lite” devices do attach properly and are successfully enumerated when connected to a PC. It would seem as though they may have a lesser tolerance for signal levels or bus conditions than the other Huawei devices that do communicate successfully with our sensors, although I believe the behavior and levels of our sensors are all within required specs.
Hi Matt:
Is there a possibility that this cell phone only works in high speed mode?
Regards
Daninel
I have confirmed that it works with the full speed USB controller of a different MCU vendor. As a note all high speed devices attach to the bus in full speed. At this point they attempt to negotiate to high speed. This can be seen as the "Chirp K" event in the second capture. You'll notice that the device doesn't attempt to do this in the first capture which indicates that it does not correctly interpret itself as having been attached to the bus.