Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length



Pages: [1]
  Print  
Author Topic: Error hex 76 on RS - why?  (Read 255 times)
GlennR
Newbie
*
Posts: 6


View Profile
« on: March 09, 2010, 07:11:49 PM »

I have the usbwiz in a configuration where there are two USB devices and an SD device. One USB device is removable and so is the SD. The other USB device is fixed in that it is soldered on the board. I'm using SPI to send commands. I need to periodically determine of a device is present or not. The only way I found of doing it is periodically send UM 1 and SD commands and see if there is an error or not. The unsolicited events don't work well with SPI because I cannot be continually sending FFs to check for the response bytes. My CPU has a lot of other things to do. Because UM 1 and SD may select a different device it also means I have to issue DS 0/1/S again before the next RS/WS to that device. I wish there was a better way to do this.

I am also doing only RS and WS commands. The problem I see is that while I am reading and writing sectors to my fixed device, and periodically sending UM 1 and SD (every 3 seconds or so), after a lot of sector I/O I eventually get error code 76 on the RS command (can't remember if it happened on WS). It appears after a lot of playing around that if I put a 150 ms delay before and after any device switch (DS 0/1/S) command, I don't seem to see the error anymore.

Could it be that the usbwiz doesn't handle back to back: WS - UM 1 - SD - DS 0 - RS ? This is my failure scenario. WS returns ok, UM 1 returns ok (because a device is inserted), SD returns 04, and DS 0 returns 00, and RS returns 76.

Strangely, I believe the error 76 does NOT occur if UM 1 returns 04 (no device) when I run this stress test (I don't insert this USB device).
« Last Edit: March 10, 2010, 10:09:28 AM by GlennR » Logged
SupportAdmin
Administrator
Hero Member
*****
Posts: 5394



View Profile WWW
« Reply #1 on: March 09, 2010, 07:27:55 PM »

Sequence of commands or stress shouldn't cause errors. This is usually caused by missing bytes in comunication.
Logged
GlennR
Newbie
*
Posts: 6


View Profile
« Reply #2 on: March 09, 2010, 10:54:18 PM »

Are you suggesting missing bytes in communication over the USB bus to the device? Or that bytes are being dropped over the SPI bus between the main CPU and the usbwiz (which doesn't seem to make sense as the command/response interface appears robust)?

I was hoping I would get more insight as to what exactly causes your result code 76 which in the manual says "76 Timed-out waiting on a response from the USB device."

Logged
SupportAdmin
Administrator
Hero Member
*****
Posts: 5394



View Profile WWW
« Reply #3 on: March 10, 2010, 08:20:32 AM »

I see now, your description of the error is caused by bad communication (SPI, UART...) but the error code you are seeing changes that!
Timeout error occurs on USBwiz asks the device from something and the device doesn't respond. This error is not related to USBwiz itself or to the order of commands, it is simple the device not responding. Now, this error is no fatal error you can simply retry the command
Logged
GlennR
Newbie
*
Posts: 6


View Profile
« Reply #4 on: March 17, 2010, 09:24:23 AM »

On this topic as I have been experimenting finding the right command sequences to do what I want, I found that doing this sequence of commands, regardless of how long I wait between them, fails:

UM 1
RS 0
RS ..
RS ..
.
.
II 1
RS 0
-> Works, followed by:
II 1
RS 0
-> Fails error code 0x65
Any subsequent RS 0 commands fail 0x65.

I discovered the following works:

Delay 30 ms
II 1
UM 1
RS 0
Delay 30 ms
II 1
UM 1
RS 0

I really wish USBwiz had a command that just told me if a device was inserted or removed, in a non-intrusive way to your state machine (different to the unsolicited events).

Any information you can provide as to the inter-dependencies and correct order of use for UM, II, RS, WS, DS? What is error code 0x65?
Logged
GHI_Support
Administrator
Hero Member
*****
Posts: 1252


View Profile
« Reply #5 on: March 17, 2010, 01:55:55 PM »

From User manual on II: "Note: This command resets the device.", so you cannot use like this....
Maybe look into EV command
Logged
Pages: [1]
  Print  
 
Jump to: