The problem is:

After undetermined time the USB of the CPU sends no more data out to PC (The in-way of the USB is blocked!) Why? I read about this problem here in this forum - it was an another CPU as mine, but the effect was the same. The experts here give always the same answer: "NOISE"!

But why? I used for my test project 4 standard near "low power" computers (laptop, office desktop, and so far) AND ORIGINAL C8051F320-DK EVALUATION BOARD from Silabs!!! Even the USB cables are from Silabs dev.kit.! Why noise? This means that the evaluation board of Silabs is not designed properly? Ok, this may be not 100% sure. But what sure is, is that i found why the USB is hanging.

--------------
Wahat happens, if i send a data packet from CPU to PC? Simple:
If the CPU write a packet into send buffer - this packet will be transferred to the PC. A byte in the software signalise, that the output buffer is busy and new data cannot be writen to the buffer. An interrupt should be generated in the CPU after the send buffer stay free, and this will cause, that the programm can write again new data to the output buffer.
BUT! What happens, if the CPU generated this interrupt NOT? Or if the flags of the CPU status registers will be not properly analysed by the CPU software? Then this flag will hang and indicate that the send buffer is busy - FOR EVER!
And this happens sporadic by some Silabs CPU's with USB interface.

I wrote a simple modification in my C8051F320 software. If i write a message to the USB buffer, i start a timer and set his reload value to approx. 500ms. If the USB interrupt was comming before the timeout of this timer - then i stop the timer and all is ok. This happens under normal circumstances always. BUT! If the USB interrupt give after (properly, or bad) USB datapacket trasmision the output buffer not free - then in the timer ISR will be set the buffer for free and the USB interface will be "reanimated"!!!

Here the timer ISR code:

------------------------------------

void Timer0_ISR (void) interrupt 1
{
EA = 0;

// there is testcounter for USB_In hanging status

if(EP_STATUS[1] == EP_TX)
{
if(USB_SUPERVISOR_COUNTER-- == 0)
{
USB_SUPERVISOR_COUNTER = Timer0_USB_IN_ReldVal_Long;
Set_Idle();
EP_STATUS[1] = EP_IDLE;
Led1 = 0;
Led2 = !Led2;
}
}

EA = 1;
}

------------------------------------

The LED's indicates, if this was caused. WAS! After approx. 10 minutes, or until 10 hours - the LED's are comming. Without those timer avent the USB-in way were hanging for ever!

Please analyse (if you can) a better way to solve this problem. But as begin this timer may be a relatively acceptable "first day" solution. It can be, that the USB interrupt is comming, but not properly analysed by software - will do next week.

What is the firmware code to be analyzed?
Show it.

PROBLEM: After indifferent time the USB send no more data to computer: USB-In communication is dead. (Receive path, USB-Out is still working.)

WHY?: The status byte flag EP_STATUS[1] for the corresponding endpoint 1 stay fixed on EP_TX status - that do not allow to write new bytes to the output buffer of the CPU

SOLUTION: The handling of the EP_STATUS[1] byte seems not 100% ok. You should test not this buffer for status before send, better way is to check directly the INPRDY (aka rbInINPRDY in the Silabs software) hardware status bit of the CPU! This bit is writen to log.1 by the software, what starts data transfer of new message to PC. This bit will be cleared automaticaly, if the send buffer stay free. This mean, that either the buffer has no more data, or - if dual buffer was enabled - that one of two output buffers is free. (That is enough for send ) In both cases, one buffer is sure free and new message can be writen to the send buffer.

I have tested, that althrough the INPRDY == 0 (==buffer free), the EP_STATUS[1] is still EP_TX !!! (That is the state, if the USB will be go on the "hanging mode". Buffer is free, message was sent, but status byte EP_STATUS[1] is wrong! And CPU idicates thru INPRDY status bit buffer for free. Then why do not use this bit? As solution, simply change this in the software:

BEFORE:
--------------------------------
void SendPacket (unsigned char ReportID)
{
...

POLL_READ_BYTE (EINCSR1, ControlReg);

...

else if(EP_STATUS[1] == EP_IDLE)
{
// the state will be updated inside the ISR handler
EP_STATUS[1] = EP_TX;

...
--------------------------------

AFTER:
--------------------------------
void SendPacket (unsigned char ReportID)
{
...

POLL_READ_BYTE (EINCSR1, ControlReg);

...

else if(!ControlReg & rbInINPRDY)
{
// the state will be updated inside the ISR handler
EP_STATUS[1] = EP_TX;

...
--------------------------------

I do not know, if this is enough as solution for this problem. I mean, that if the status byte EP_STATUS[1] was handled wrong, then may be the handling of it is wrong on other places too. ??? As first aid for the "NOISE" problem is this solution good for me. The software and USB communication is working about 48 hours good for me and the USB is working wery well. In this 48 hours was happened about 3 times, that in the SendPacket() routine was software status byte EP_STATUS[1] == EP_TX (buffer busy) althrough hardware status bit rbInINPRDY == 0 (buffer free) !!!

Yes, i know what is noise on the USB. But, not this was the problem. Problem was, that the CPU was hanging! Error may be - but the USB must running again. The inconsistence between software status byte EP_STATUS[1] and hardware status bit rbInINPRDY occur this problem. The software set the EP_STATUS[1] for free into one alone place in the USB interrupt handling routine. But in any cases (double buffering or similar) the CPU must not always generate this interrupt, or if it will be generated, must not be comming with bit-status that causes the right handling of this status. Althrough the output buffer changes to free.

I say: USB may have corrupt data transfers, but the software must solve this and communication be on! I do not like hanging CPU's

Bad/missing power supply smoothing.
Improper termination of signal/shield ground.
-----

Hm, can agree, but it was tested with about more than 5 computers, any of them "low power". HP, Lenovo, noname and so far. And the other side - original C8051F320DK evaluation board with supply adapter and USB cables - all original from Silabs! What i does wrong?

Based on your post, we have initiated the process to update the relevant examples to reflect the data sheet guidance.

The "Reserved" bits in question influence the behavior of the clock recovery circuit in the USB transceiver. It is unclear whether the '0x80' CLKREC register setting would cause a "1 in 100,000" class of error. In our experience (which includes all of our customer interactions to date on the USB MCUs), we haven't seen it. But then again, infrequent intermittent problems are often difficult to reproduce and address, and it is best to remove the possibility of it causing a problem in the future. It certainly can't hurt.

Thanks again,

While you are at it, don't forget:

FLSCL |= 0x90; // set 48MHz for flash

At the bottom of the clock set if you are using USB_4X_CLOCK.

This is missing from the examples as well.

Most of the USB examples for the 'F340 use the 4x USB clock for the USB peripheral (USBCLK), but use the internal 12 MHz oscillator or the USBCLK / 2 ( = 24 MHz) for the system clock. In this case, no modification to the Flash Read timing bits is needed because the system clock is operating at 25 MHz or less.

The MSD USB example *does* have this bug, which is probably why you are noting it. Also, the 'F34x_UART_MultiUART.c' example operates at 48 MHz but does not set the Flash Read timing bits correctly. This is also on our list of examples to update.

However, you are correct. If the system clock is operating at 48 MHz (or any frequency above 25 MHz), it is absolutely essential to set the Flash Read timing bits appropriately.

Regarding CLKREC, we are not changing our recommendations regarding the correct setting. The data sheet, which is the ultimate source for device usage recommendations, has listed the 0x89 value since initial product release. Instead, we are bringing the example code into compliance with the data sheet recommendations. From the looks of things, this appears to be a bug in some original USB initialization code that has propagated via copy/paste throughout most of the USB code examples.

Also to be clear, changing CLKREC from 0x80 to 0x89 will not introduce new problems to a system which is already working.

Thanks,

chage the line:
else if(EP_STATUS[1] == EP_IDLE)
with those:
else if(!ControlReg & rbInINPRDY)

My original developer board for C8051F320 is running after this change near 2 months without any break or hang up!!! (No watchdog or other check activated!) Before i have hang-up many times for a day, now absolutely nothing! A USB cable "NOISE PROBLEM" was here solved for me.

I try to test the other changes, but on my other board with C8051F340, because the F320 what i have used till today can run maximal 25MHz. For those frequencies the change of those 2 lines is enough.