Bad reads from XEM module


#1

I have set up a buffered pipe and some wires showing the status and I have been getting some very strange issues on the PC side of things.

Sometimes when I read the Wires I get all ff’s when I know that some of the bits must read 0. When I get these bad reads it is apparent that all addressed wires are bad, reading either 0xffff or 0x0000.

I get a similar issue with the buffered pipe read where occasionally I read back all 0xffffs or 0x0000’s instead of the correct data.

I see this issue with the Java API and also the C API.

Any thoughts on this appreciated - I am dead in the water if I can’t get reliable communications between the XEM and the PC… :frowning:

Thanks in advance.

Cheers!


#2

Phloyd, some of these issues can be caused by version inconsistencies. Please make sure you are using the latest version of FrontPanel and are using the latest API’s, libraries, .ngc files, etc.

If this doesn’t solve your problem, please post back here some more details about your project and I’m sure we’ll find a solution.


#3

I’d like to elaborate a bit on this topic.

The primary (only?) incompatibility comes with older versions of the API combined with new versions of firmware. New versions of the firmware may add/remove/change certain communication protocols between the host and firmware. The new versions of the API are aware of these features and also aware of which firmware supports them.

Unfortunately, old versions of the API cannot be aware of them. Therefore, we suggest either recompiling the application or installing the latest API DLL.

If you have tried using the latest files (.h, .lib) and are still having problems, please let me know. We’re working on a new way to version all these components (API, firmware, and HDL modules) in an effort to keep things more consistent.


#4

I have not made any progress with this.

I have a fresh install of 1.2.5

I am using the Counters bit file and reading the count (ep20).

On occasions I read 0x00 or 0xffff instead of the correct count

I am using VC6 - I wonder if there is an issue there with the version of the API?

I will try using a different API perhaps… haven’t tried Python yet…! :slight_smile:

I would be happy to share this code to see if the issue can be replicated…

Cheers!


#5

Yeah, so if there is any recommendation regarding file dates or anything like that to ensure that I have compatible versions of things, please let me know.


#6

Wild!

I can see the issue when running the Counters application that shipped with the 1.2.5 software!


#7

Sorry to be spamming here, but it really does look like the Counters.exe and the VC6 lib were not updated - where the other lib is dated 8/1/05, the other apps and libs are older.

Can these please be updated so that it all works together…???

Cheers!


#8

Ah, you’re using VC6. It appears that that build of the library did not get updated on v1.2.5. I apologize for that inconvenience.

In a few days here, we will be releasing v1.3.0 and will be updating everything for that release. Can you wait for this new release? If not, I can try to rebuild the vc6 library from the 1.2.5 code.


#9

I can probably wait… depends how few a few is :slight_smile:

It would be great to get working on this soon if possible… I guess if the new code is done by next weekend it would be best if I start with that.

Thanks - I appreciate your prompt response. I can’t wait to see this all working :slight_smile:

Cheers!


#10

One other thing to mention is that we may eventually get rid of the C++ library due to the portability issues. VC8 is in beta now and folks are still using VC6. We may simply support the DLL and, possibly, a COM object.

Would this cause a lot of grief?


#11

I am somewhat of a beginner with respect to VC6 and windows coding in general so I am sure that I don’t know the implications of what you describe.

For me, as long as I can compile, link and it works I am happy.

Cheers!


#12

Well, for the moment, the C++ library will be availble. There are several problems with “static linking” as this is. First is compiler compatibility. The library must be recompiled for different versions of the compiler (VC6 and VC7. Possibly VC8) It also must be recompiled for different compilers (Borland). The same issues exist on Linux, of course.

Dynamic linking is preferred, but comes along with its own problems. The current DLL is C-only and doesn’t support the convenience of some of the C++ structures we would like to use. A COM object would potentially solve some of these issues.