Need to confirm the connection to the card

[gDeChoulot]

I am doing a studdy concerning your X3-A4D4 card since a few days, and for 2 month or less.

I took the examples for this card: X3-A4D4/SNAP.

I followed the instruction of Malibu documentation in order to create a visual studio 2010 project.
I used SNAP/Common/ApplicationIo.cpp/h.


1) When I try to connect my applicationIo instance to my card, using ApplicationIo::Open() in order to link the class to hardware, sometimes I get:
"Module Device Open Failure"
(unknown exception)
I get the same result when I use SNAP.exe (playing with open/close)

The only way I found to get over it is to reboot...
Somehow, I guess the ApplicationIo::Close() which I always call, is sometime not enough?! Is there a better way?

2) When connection to card succeed (I am almost sure it do because I can play with the ApplicationIo::LED() as the X3-A4D4/Applets/Finder.exe do)

when I call the method: ApplicationIo::ModuleName()
which is supposed call X3-A4D4::Name(), which call
X3-A4D4DeviceMap::Name(), it return X3-SD instead of X3-A4D4?

(ApplicationIo.h well define a Module using Target.h file :
...
#include <X3_A4D4_Mb.h>
#define PmcName "X3-A4D4"
#define PmcModule Innovative::x3_A4D4
...

Please I need to confirm that I am connected to the card which is: X3-A4D4 in order to go to the next step. Let me know if you have any idea to solve this, or need more relevant info...

Thanks for any help

[jhenderson]

The current version of the driver is exhibiting BM allocation failures when running under Windows7. This problem is not present under earlier versions of Windows. So if possible, allocate the minimum amount of BM memory (4 MB) and/or work on another OS until this problem is resolved.

The board type detection code is incorrect. Use the information displayed on the EEPROM tab instead until this is resolved.

[gDeChoulot]

I have been amusingly surprised by your short answere. Thank you.

I confirm I'm using Windows 7, and we were already planning to change the OS to Windows XP.
I have also used ApplicationIo::testZbt() which confirm memory allocation failures.
I will receive a second plateform with Windows XP soon so, my both problem might be solved as you said by using the XP driver.

The information in the EEPROM tab was incorrect (X3-SD)
so I corrected it (EEPROM is writtable) and I used the ApplicationIo::WriteRom() and now using ApplicationIo::ReadRom() I get the information I wrote in it, but since I wrote it myself, and since it's writable it does not confirm that the driver/connection/hardware is correct.

thank you! I will keep going thanks to you

[jhenderson]

If you successfully open the driver using the supplied Snap or Wave executable, are you able to stream data successfully? If so, the driver and hardware environment is viable and you should be able to commence development.

[gDeChoulot]

For now, I have a stream but I am waiting for power supply in order to simulate the input Signal, because I can't confirm that what I get is right.
(and for my oscilloscope to check my output).

But I don't think that opening without exception really confirm that the connection is right because when I opened the connection using the wrong include and library (for another card: X3-SD), and the connection seems right too (I could make the led blink).

So anyway, I can't check the stream value.

The only thing I can see is that the method ApplicationIo::Name() return the wrong name, and the method ApplicationIo::testZbt() is returning something like 600,000 errors...
So I guess something is wrong with the connection with the windows 7 driver as said earlier.

I will be receiving the new plateform, windows xp equiped, and my power supply soon. Thank you for your concern anyway!

Have a good week end!

[jhenderson]

The module Name() function queries the user logic firmware to determine the type code, which is translated into a board name. The mapping between firmware type code and name is as follows:

X3 SD 0
X3 SDF 1
X3 A4D4 2
X3 DIO 3
X3 25M 4
X3 Servo 5
X3 10M 6
X3-2M 7
X3-Timing 8
X3-SD16 9

It is not possible for the software to unambiguously determine the module type unless the firmware has been loaded. But one But, each board firmware is unique so the appropriate firmware must be loaded on the FPGA for the specific card in use. This results in a "chicken or the egg" problem.

In summary, the Name method cannot be used to uniquely identify the X3 module type.

Use Finder to identify which card responds as target 0. Look at the silkscreen labeling on that card to determine it's type. Then, use that information to load the appropriate logic into that target.

[gDeChoulot]

Everything works properly since I received the new xp plateform.
The same code is now working.

The connection is closed properly which was not the case before, so I don't have to reboot each time I open the connection, as I had to before.

The analogic data I get is the sampled data I send.

I'll keep going, thank you.

[jhenderson]

Issue closed.