Software resetting an 8451 SPI?

[SparkyJoe]

Afternoon all, not entirely sure if this is the correct board for this, so if not my sincere apologies and any pointers to the correct board would be most welcome.

Anyway, to the nub.

I'm using an NI-8451 SPI/I2C interface pod to control an SPI controlled Scintera lineariser IC, but occasionally it looks as if the 8451 enters some sort of recalcitrant mode and refuses to return anything other than 0xFF on the SPI bus.  I'm using LabVIEW 2012 SP1 and am using the basic 8451 palette.  Due to the send-command/read-returncode nature of the device, the advanced scripting palette is a non-starter.

The problem seems to manifest itself when an SPI opcode is sent before the lineariser device has finished booting.  My reason for sending opcodes prior to boot completion is to try and achieve some sort of synchonisation between the DUT and the ATE, rather than using an arbitrary delay function.

Up until this point, opcodes are sent and appropriate data and returncodes are received.  I can even open the manufacturer's GUI and send and receive data over the 8451 too.  However, should a command be sent following a DUT power on slightly prior to boot completion, then any request for data or returncodes will read only 0xFF.  No amount of DUT power cycling or resetting will clear the problem.  In fact, the only way I've found to clear the problem is to exit LabVIEW, remove the USB connector from the 8451, count to ten then reconnect and restart everything.

Also, while the "system" is in its 0xFF mode, the manufacturer's GUI won't work either, responding only that the device is constantly resetting, that the firmware is incompatible with the device or that either the device or the 8451 isn't powered on.

While the unplugging fix works, it's not particularly suited to a factory environment, so I would like to find some way of issuing a reset to the 8451 from LabVIEW.  Unfortunately, there doesn't seem to be any way to to this, even from MAX.

So to get to the point then, does anyone know why the system would enter this 0xFF mode in the first place and/or how to reset the 8451 without needing to unplug everything.

For info, the eight DIO lines still work fine.

All suggestions gratefully received,

Steve

[Larry.C]

Hi SparkyJoe,

Would it be possible to employ a system which calls a DLL function that makes the necessary calls to windows to reregister the USB device? I think this is the only way that you can software reset an 8451. To do this I found the following information:

From kernel mode: You can force a specific USB device to be re-connected, as if it was unplugged and replugged again, by sending an IOCTL_INTERNAL_USB_CYCLE_PORT to its PDO. (This can only be done from a kernel mode, e.g. through a helper driver.) This 'cycle' operation will cause a USB reset to occur, after which the device would be re-enumerated. For example, if the device comes back with a different USB device descriptor, a different driver may be matched for it.

From user mode: You can do this by ejecting the device through the CfgMgr API. For example, to go over all USB hubs and eject all devices:

1. Find all devices having device interface GUID_DEVINTERFACE_USB_HUB withSetupDiGetClassDevs(... DIGCF_DEVICEINTERFACE).
2. Enumerate over the returned device information set (SetupDiEnumDeviceInfo).
3. For each device, get the DevInst member:
   1. Invoke CM_Get_Child(DevInst) and then CM_Get_Sibling repeatedly to go over all child nodes of the hub (i.e. the USB devices).
   2. For each child node, call CM_Request_Device_Eject.

I believe you will need to use the "From user mode" method, and the DLL in question I think is the setupapi.dll in the system32 folder in windows.

The information was taken from here.

I hope this information helps,

Kind Regards,

[Larry.C]

Hi SparkyJoe,

Have you been able to use a dll call to try to reset the USB device?

I have been having a further look into this and was wondering, is there a possibility that you are performing some sort of clock stretching in your system? This can cause problems with the module causing it to lock up.

Kind Regards,

[19jmc]

Hi Larry,

I had the same issue but managed to create a small VI that effectively 'resets' the device. 

It uses the devices drivers in order to allow the SPI port pins to be put into a tristate mode, which solved all of my issues!

It does require the NI USB 8451 drivers.

I hope this becomes useful for someone in the future.

Regards,

John Mc

[19jmc]

I have now posted the suggestion on the Community Example forum here:

https://decibel.ni.com/content/docs/DOC-26659

[Larry.C]

Hi 19jmc,

Thanks for posting your solution to resetting the 8451 module. It seems like a really useful example so I will be adding it to my list of "programs which solve problems".

Kind Regards,

[Lag66]

I, 

It's maybe late...or not lol.

I should be connect to an SC1894(and 1889) scintera linariser in automatic workbench, i looking for found drivers anywhere.....so...

Do you have any information on :

- can i connect it with usb /digital I/O NI converter

-can i connect it with arduino ...maybe....lol

-can i use programme , DLL or other scintera interface with labview to send/received data to/ from scintera controller?

Thanks all,

Romain