BUT!

The communication will be dead after indetermined time interval. It may be dead after 1 minute, or 1 hour, or will be running longer than 1 day. I think, that the USB firmware routines have a bug, or the low-lewel implementation is bad. Now i wish intensively test this, but i do not know how! Have you (event. solved) such problems?

May be, the input buffer will be full, but the function returns bad value? Can i analyse this and give the communication a reset? Or the send routine have inaccesibble buffer? Or the message will be not sent properly and the buffer stay busy for ever? Or, or, or, ...

Apropos: Have read here on forum about blocked USB communication, because the power supply was noisy, or the USB signal was disturbed or similar. How to solve such a dead USB communication? Is true, that a communication interface will be busy for ever?! It must exist a solution to determine such error status and kill them. May be this is the same problem as i have, but USB is an interface, that should solve error states automaticaly and not hanging up forever? Help please, because all works properly, only the USB dont!

(On which points may be good give breakpints to determine the working state of the communication?)

Software sniffer can't see good clue after the hang occurs. If it would record traffic before the trouble occurs, it may catch any clue. But I'm not sure sniffers can hold trace for an hour or more.

Random error is often caused by noise.
Noise affects to on-chip OSC, and it results missing / excess clock pulse.
USB PHY is more sensitive to clock disorder than MCU core.

As a second way to solve this problem were following "soviet way" - if we cannot find the source of those errors (apropos - it is the original C8051F320DK eval. board!), then we should healt the errors - how to modify the Blinky code, that if until 5 seconds no succesfull transmission happens in the needed direction, either a watchdog reset, or - and better - a reinitialisation of the USB interface on the 8051F320 will be done! This will be made to run communication over USB again and the buffers of serial interface will be unattached and can be send again! Better one silent reset in 4-5 hours, than pay 3-4 watchmans, to observe the equipment 24 hours on a day. How can i do softvare reinitialisation (may be with right initialized watchdog with prescaller) of the USB interface? Best as example for the existing example (HID Blinky ??? )

Apropos - this is my second unsolved problem - do the drivers please able (with examples) to make possibble event driven programms in the VB.Net - no polling pls.! No C++ please - we are experts in metheorology, hardware technik and so far., but not professional programmers. We do simple application oriented programms only. From scheme, layout, to slodering, programming - all especialy made for our test equipment. C, VB6.0, VB.Net, 8051 assembler, ... but so sorry, not C++. Mea culpa, mea culpa, ... i know, but its true!

IF DEAD USB HAPPENS, THEN THE IN DIRECTION IS DEAD, OUT IS STILL ACTIVE!

By dead USB connection my host programm in VB.Net is still living, if i does reset them or not, the situation will be the same. USB packets from C8051F320 CPU into PC (IN packets) are not generated, because the USB routines in the CPU signalize busy interface.

The OUT packet way is working well under those circumstances, packets sent from PC to CPU will arrive OK, and all other routines in the CPU are working well too. RS232 interface, A/D converter, ... , and all related interrupts are ok.

Only the packet send function "void SendPacket (unsigned char ReportID)" will be returned without any action, because both conditions are false:
"if (EP_STATUS[1] == EP_HALT)",
"else if(EP_STATUS[1] == EP_IDLE)".

This signalise, that the send buffers going newer to IDLE status, allthrough no data are more sent to PC! PC site is not guilty on this mistake, beause the reset of PC sided software establish the connection not. Only reset of the CPU alone turn the communication again on!

Then my question:
Why sent the CPU not the output buffers out, or why do not make the CPU the output buffers free - in IDLE status? The PC side will potentialy receive packets, but the CPU do not sent they out. How to solve this? May be, this is much more a problem of Silabs to solve this, because many of users complain about near identical hanging USB interface. If Silabs have hardware USB analyser - as recommended - then is easier to analyse that by the company itself, as by each user separately. And, by the way - i think, it is so hardware and firmware near problem, that Silabs is predestined to work on optimal solution.

[This message has been edited by stu (edited July 01, 2010).]

And - if the noise problem is present by many users - why do search the problem in the noise, if may be, the hardware or firmware on the Silabs chip is bad?!

And - if this problem is present, it must be the way, how to detect this "hanging state" of the MCU to kill them in the software!

END MOST IMPORTANT - if this problem is present by Silabs MCU's, the any shielding and "denoising" helps to sink the sensitivity for those effects, but not healt them! In case of stronger noise, or electricity impulse such interface will be hang again! The USB interface was made for work with noise signals too - no hanging is allowed. It must detect and repeat disturbed packets itself - may be 1-2-3 packets will be lost, but the interface must live.

So sorry, but i think, we will healt problems that are on the MCU side.

USB is designed for continuous operation under noisy and disturbed connections too! Packets may be lost, but never can crash and for ever hang the connection! If this happens, something is very, very wrong! Reset, or watchdog is a solution for catastrofical case, for handling extraordinal exceptions, but not as solution for normal working equipment. (And as i told before, mine equipment is very, very optimized in my laboratory, without high power devices, so that no horrible disturbances can occur.)

I think, the MCU is not ok. To healt the consequences instead of real causes is not acceptable. If this happens only by me, than i can think i is my problem. But if this happens by other MCU, by other users and under different hard/soft circumstances too, than i can think, that the implementation of the USB interface in the MCU is wrong. The solution recommended by Silabs, with optimized USB noise, can reduce the probability of communication failure, but never eliminate it on acceptable level. It is my position, i will be happy, if i am wrong!

(Here may be come the post from Silabs )

So, i think, that the problem occur if an IN packet will be send from CPU to PC and the CPU does not set the EP_STATUS[1] byte to right value. The EP_STATUS[1] hang on status EP_TX for ever !!! Why? May be, that the firmware does not generate the interrupt after transfer ?! If the transfer was done ok, then the interrupt generated via the CPU must set status to EP_IDLE, or if the transfer was bad, then the interrupt must set the status to EP_STALL or EP_HALT (i am not USB expert, do not know, what is better in this case). If the interrupt was under concrete circumstances not generated, caused that the status is fixed as EP_TX and all next comming USB-In packets will be rejected! The PC as master cannot reanime the communication - because the PC knows not about the problems on CPU side. The communication way for OUT packets from PC to CPU is still running and the PC have no other information. The test, if the CPU USB-In communication is hanging and the reanimation of it must be done only in the CPU alone.

I have tested -after the USB communication was hanging again - simple stop the CPU programm execution, set manual the EP_STAUS[1] to EP_IDLE - and voila! The USB communication is running again. Hureka!

The questions are now:

1.) how to simply detect, that the USB-In is dead?
May be on this way: If the USB_In is dead, then after each call of SendPacket() should be tested, if the EP_STATUS[1] is equal to EP_TX - if yes, then start a timer and after timeout set the status to EP_IDLE!

3.) Most important for the 100% solving of this problem - why the CPU does not right handle the USB-In trasfer?

I make next week new, modified routines to solve this problem and make a post here.
BUT! What say Silabs oficial to this problem? I think, that not each user of those CPUs should buy a hardware USB analyser - i think, that Silabs have one, or more of them. And Silabs know the internal structure and firmware of the CPUs most better, than any user. So please Silab - can YOU analyse this problem?

http://www.cygnal.org/ubb/Forum9/HTML/002088.html