Using it in host mode I find very often return code (0x0D == hrJERR) when using the following routine:extracted from the sample 10 - differently my board uses a PS80C435 processor.
BYTE Send_Packet(BYTE token,BYTE endpoint) { BYTE resultcode,retry_count; retry_count = 0; // set retry_count to 0 nak_count = 0; // set nak_count to 0 // while(1) // If the response is NAK or timeout, keep sending until either NAK_LIMIT or RETRY_LIMIT is reached. // Returns the HRSL code. { Hwreg(rHXFR,(token|endpoint)); // laugh at the transfer while(!(Hrreg(rHIRQ) & bmHXFRDNIRQ)); // wait for the completion IRQ Hwreg(rHIRQ,bmHXFRDNIRQ); // clear the IRQ resultcode = (Hrreg(rHRSL) & 0x0F); // get the result if (resultcode==hrNAK) { nak_count++; // raize the count if(nak_count==NAK_LIMIT) break; else continue; // continue } if (resultcode==hrTIMEOUT) { retry_count++; // raize the other count if (retry_count==RETRY_LIMIT) break; // hit the max allowed retries. Exit and return result code else continue; } else break; // all other cases, just return the success or error code } return(resultcode); // return the resultcode }
retry_count = 0; // set retry_count to 0 nak_count = 0; // set nak_count to 0
return(resultcode); // return the resultcode
These comments are completely worthless as they add nothing that is not directly and immediately obvious from the code itself!
They should be removed as they just add clutter - ie, they give no benefit and cause a small amount of harm!
"They should be removed as they just add clutter - ie, they give no benefit and cause a small amount of harm!"
I can only agree. When the code is obvious, the comment should not try to duplicate function in a different language.
It is bettery to spend time to document "why" things are done, than to tell what is done. Any sw developer who fail recognize that you set a variable to zero are a liar, since they claim that they are something that they obviously aren't.
Write documentation for a sw developer, not for a fool.
"Usb maxim" is not sufficient to specify the chip you are working, even if Maxim has only one product, MAX3421E, which has USB host function.
hrJERR just shows the target device doesn't respond. Maybe, the bug is not in the code of your post, it lies on the other part of your code, or on the target device side.
Do you have a hardware USB analyzer? It is 'must' for the host side development, even for simplified chip like MAX3421E. Monitor the bus traffic just before the error occurs.
Also, does the target device work perfectly with a PC test application? As the first step, make a test application on PC to run the target device. Then, monitor the USB traffic between the target device and PC by the analyzer. And the last step, implement this traffic to your embedded USB host. When you come across the error of your post, compare the bus traffic of the embedded host to the PC one. Then, you'll find immediately what is wrong.
It may sound like a roundabout way. But you'll find this way is the short cut after all.
Tsuneo