1
\$\begingroup\$

I am porting the USB driver from the STM32F4 device to STM32L4 device. It almost works. During the enumeration it sends and receives the information, but the data is not exactly the same as from the "plain" STM Cube generated project. II have the same settings in both project but get the strange results.

I lost a week trying to find the solution, maybe someone here had a similar problem and can help me out. Sorry for the images but there is no other of posting some informations on the SO

enter image description here

As you can see the packets are almost the same, but not identical. After 25th transmition the board stalls and accepts only very limited number of the requests

The both files form the wireshark (in the wireshark and text formats) are here:

https://gitlab.com/diymat/usb-problem/tree/master

The ep* files are form my port, stmcdc* - STM Cube generated one. Both were running using the same hardware.

\$\endgroup\$
  • \$\begingroup\$ At a guess, I'd say that's a device ID that may be masked into the part. \$\endgroup\$ – Cristobol Polychronopolis Mar 18 at 16:08
  • \$\begingroup\$ this information is easily rendered into textual form, and it is your job to do that rather than make people squint at your screen shots. \$\endgroup\$ – Chris Stratton Mar 18 at 16:13
  • 2
    \$\begingroup\$ illicitly crossposted at stackoverflow.com/questions/55225487/… \$\endgroup\$ – Chris Stratton Mar 18 at 16:18
2
\$\begingroup\$

You need to check your physical layer for compliance to USB electricals. Usually this type of "unstable" behavior is due to frequency of one USB partner deviating more than USB allows (+-2000 ppm for FS and +-500 ppm for HS, plus some headroom).

The issue is that all enumeration packets are relatively small, and there is not enough time for receiver to accumulate significant difference in edges, so enumeration kind-of works. Yet on longer packets the error creeps in, and hits CRC, and transmission fails.

If USB transmits everything without errors but your data mismatch occurs at internal buffer level, you need to check your transport protocol level software.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.