Part Number: MSP430F5529 I have some projects running with MSP430F5529 and USB. The first one started in 2012 and uses the TI-USB Framework which was current at that time. Newer projects were created with more recent versions of the TI-USB Framework. Since we didn't want our customers to install additional drivers, we made all of them HID. Things are going well so far. But in rare events, there seem to be some problems with USB communication. The MSP seems to send corrupt data to the PC once in a while. I tried to find the cause for that and inserted a constant byte pattern which the MSP should send to the PC. Looking at the result, it seems like some bits are shifted. The first bytes are correct. When I traced the bytes' path through the API code (hidSendDataInBackground or the more recent USBHID_sendData), I could not find any point where things could possibly go wrong. Since this happens with different framework versions, I doubt this is a code issue. And since high-speed data transmission is possible with even poor layout (see https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/346138/1215821 or http://forum.43oh.com/topic/2775-msp430-usb-benchmark/ ), I would assume that this is not a layout issue also. EMI could surely lead to transmission errors, but this is covered by the low-level CRC which is included in any USB transmission. The CRC succeeds, so the transmitted data is assumed to be correct. But as I mentioned, the data which is received by the PC is corrupted. I made a Workaround for the more recent projects. I performed another CRC in Software on both (MSP and PC) side which works, there are no more "corrupted" transmissions. The software CRC fails if there are any "shifted" bits. But this seems a little over the top for me, since there already is a CRC in USB communication which normally should prevent transmission errors. Also, I'm losing 2 bytes of transmission capacity since I need those for the checksum. But the worst thing is, I can no longer rely on the API to split packets of more than 64 bytes automatically. Instead, I have to do some work in the code (MSP and PC) to split larger packets and stitch them together again. This seems like a little unnecessary overhead, too. Did anyone of you encounter this before? Does anyone have experiences with this kind of problem? I looked through the forums and also did some extensive Google research, but I could not find any hints to the cause. Also, though this happens rarely and is hard to reproduce, this is crucial for data logging applications; one single corrupted measurement might corrupt entire calculations, if there is no further plausibility check (which should always be done, but needs to be much more detailed to catch these errors).
↧