Strange USB Behaviors

[Loren]

Greetings,

Sorry if I am posting in the wrong place.  Maybe someone can point to the correct forum for me.

Problem: USB HID 04 Joystick intermittently sends incorrect 12-bit analog data.

Micro: STM32F103R8T6

Details: A 1/2 Hz signal applied to analog inputs that vacillates above below an 8-bit boundary (i.e., 2047 to 2048) I sometimes get a value of 1792 or 2303 decimal sent.  It appears as if the upper 4 bits of the 12-bit word is out of sync with the lower 8 bits and subsequently sends 0x700 instead of 0x800 or 0x8FF instead of 0x7FF.

The problem was first discovered using a Microchip 8-Bit microcontroller.  No one could solve the puzzle, se we went with an NXP MK20DX256VLH7 32-bit processor and the problem went away.  NXP has a 1-year lead time, so we switched to ST Micro.  Now the problem has returned with the F103 part.

To eliminate the possibility of data corruption of the USB structure we put in a trap just before the call to: 

USBD_HID_SendReport(&hUsbDeviceFS, (uint8_t*) &gameHID, sizeof(struct gameHID_t));

To test for something wrong with the analog DMA data we parsed that data for out-of-bounds conditions, then set a fault flag.  The flag never got set, but the USB data continued to post intermittent erroneous values of 1792 and 2303 on one of the five analog channels.  This issue was confirmed on multiple host PCs using different capture software.

It gets stranger yet.  We complied the same code for an STM32F722 and an STM32F730 micro and the problem disappeared,

I can't believe this is a problem with the chip (or HAL library), so there must be something we are doing wrong with the way we have the USB configured as a Full-Speed USB (both for the F103 and F7xx).

The only thing different between the F103 and the NXP and F7xx chips is the F103 is not USB OTG.

Sorry for the long post, but I want to frame the problem as best I can.  Thanks in advance.

[Loren]

Arg!  Still did not work.  Well, my fault there...

I found out that I was accidentally modifying the wrong file from a different project.  Not good to be doing two things at once in this IDE.

So, letting the this run overnight and see what tomorrow brings.

Thanks for your help.  I really appreciate it.

[TDK]

If you can, I would consider instead sending 0x0101, 0x0202, etc... And if you can capture the sent values on the other side and post them here, that might give you better insight into specifically what can be going wrong, rather than just a general "something isn't quite right".

[Loren]

Yeah, that might be a good final check.

Right now it has been running for over an hour with triangle waves from my signal generator with no faults.

Before it would *** out within 60 seconds. 

So, at least I understand the why I had the fault.  I would expect there is a "better" way to manage this without modifying the library function.  You would think that this is a common issue, so there is probably a more eloquent way to slay this dragon.  :)

[Loren · Accepted solution]

Ran without error last night.  I'm going to call this thread as resolved for now.

I'll run the suggested test of 0x0101...0x0202... tonight as a second verification.

Thank you for all your help!