1) 1pm / 09/01/2009
2) 3 days
3) MC3090S-LC28SBAGER
4) CE5 5) Clarify Case #1959347 TA from Germany reported following and wanted to know our feedback on this. I am not attaching the logs as they are quite huge (9MB), but a screenshot from the analysis software.
Ourpartner has done some further investigations. Some of therefindings show that our own USB driver seems not to be as "clean"as we would hope it to be.
Youmay want to download the software from the below provided link from ellisys.Attached you will find two log files, one for the communication with the XP PCand one for the communication with our MC3000.
http://www.ellisys.com/support/download.php
USBCommunication to a Windows XP PC are working fine, except that we could monitorquite a number of "Nak's". Which might cause us timing problems whencommunicating with our MC3000. Toview the log files simply download the Ellisys USB Explorer 200 software.
Thanks! Petr
5 Replies
You have an interesting one, Petr. The customer has found some odd behavior in a driver, but this odd behavior isn't affecting operation right now. SPR stands for System Problem Report - but the customer isn't experiencing a problem. So, I don't think a P2 SPR applies. Open a P3 SPR on this. If we find that there is a real problem that needs to be fixed then we'll change it to P2, if we find that the communication is within spec, then we'll just close it as a P3, if we find that it's working within spec but could be improved, we'll change it to a P4. In the meantime, you should tell the customer that the driver is behaving as designed and passes our quality processes (Engineering testing and T&V). However, as we are always looking to improve you'll open an SPR to have engineering review the design. Does that work?
New P3 SPR #17657 was opened to review the USB communication issues.
Do you think that a new SPR can be raised for this USB communication issues? I don't have a possibility to replicate the issue here before opening a new SPR as we do not have tools for capturing and analyzing USB traffic so we rely on what our partner is reporting. They are now asking us for some feedback therefore I would like to somehow proceed further. Thanks! Petr.
I don't think I understand the situation. The customer is saying that the communication works fine, yet they want something fixed?
Hi George, the issue customer is reporting is that when analyzing USB traffic they can see huge number of NAKs in communication (please see the attached picture in the first post). They do not see any significant communication issues right now at this moment when just trying to connect the device with PC and capture logs, but they think that this might cause them timing problems when communicating with MC3000 device in real environment using custom application and data transfer over USB connection. Therefore they have asked us for a statement why such huge amount of NAKs are generated and if this could cause any timing problems in real scenario.