2009-05-11 10:15 AM
Possible bug in USB library
2011-05-17 04:10 AM
Can anyone confirm or deny the possibility of a race condition here? Are the endpoint register macros perhaps only usable in situations where the affected bits can't be set by hardware anyway? STOne?
2011-05-17 04:10 AM
I noticed a couple of problems with the USB library when I upgraded from 1.0 to 2.2.1.
First of all I could no longer build a library archive, because usb_type.h now tries to include usb_conf.h, which doesn't exist in the USB library. After checking the usb_conf.h from the example projects, I saw that it defines only project specific stuff, which nothing in the library depends on. And indeed, after removing the #include directive from usb_type.h, the library builds again. Can the include be removed again in future versions? Secondly, I get a few warnings from GCC about missing recommended parentheses around the bitwise and/or in the following macros from usb_regs.h: _SetEPAddress() _ToggleDTOG_RX() _ToggleDTOG_TX() Maybe this trivial change (add parentheses around ''_GetENDPOINT(bEpNum) & EPREG_MASK'') could be made in future versions to get rid of the warnings? While looking through the macros in usb_regs.h I also discovered what could possibly be a real problem. In most or all macros that change an endpoint register, the register is first read, then bitmasked to clear the toggle bits to their invariant state ('0'), all according to the register description in RM0008. The resulting value is modified according to the purpose of the macro, and then written back to the register. However, the bits that have an invariant value of '1' seem to be neglected. If they are set by hardware between the read and the write, they will be reset inadvertently. Shouldn't the procedure rather be to read the register, clear the 0-invariant bits, _set the 1-invariant bits_, then modify the value and write back?