Home › Forums › FTDI FT4222 LabVIEW Driver Discussions › Error – FT4222_DEVICE_NOT_SUPPORTED
Tagged: Error, FT4222, FT4222_DEVICE_NOT_SUPPORTED, FTDI, LabVIEW Library
- This topic has 9 replies, 2 voices, and was last updated 3 years ago by
Ajay.
-
AuthorPosts
-
-
February 14, 2022 at 10:27 am #2844
Masao
ParticipantHello!
I just activated FTDI Driver for I2C SPI GPIO.
I tested “FT4222_SPIMaster_Init”.
And got error of FT4222_DEVICE_NOT_SUPPORTED.The hardware is tested with Visual Studio 2022 by using attached code.
In that case, I can do up to FT4222_SPIMaster_SingleReadWrite.Can I have any clue to solve this problem.
Best Regards,
Masao Kaizuka-
This topic was modified 3 years ago by
Ajay. Reason: Updating the actual message received on email
-
This topic was modified 3 years ago by
-
February 14, 2022 at 12:16 pm #2856
Ajay
KeymasterHi Ajay-san
So far I tested with my FTD2XX driver and your FT4222.
Now I replace those FTD2XX to your driver.
Tested vi is below.By using my driver, I checked all port are closed.
Then invoke above session and get result below.The error happened at SPI_Master_Init.vi
Do you have any clue?Regards,
Masao -
February 14, 2022 at 2:08 pm #2870
Ajay
KeymasterHi Masao,
Can you please try with the example as shown in below using List Devices? Use the device index 1 (from your screenshot) and open by serial number for that, it will eventually give the proper flags to the FTDI OPEN to open correct device.
Thanks,
Ajay. -
February 14, 2022 at 3:35 pm #2876
Masao
ParticipantHi Ajay-san
Unfortunately no difference happened.
Revised code is below
Please note that I am using MODE3, which doesn’t generate serial number and I don’t understand
use Open by serial number.Beside I tested with MODE0, which generates FT4222 A and B,
I tested both FT4222 A and B. Both generate same error before.Since Visual Studio works fine with MODE3, this issue came from LabVIEW interface to DLL.
What do you think?
-
February 15, 2022 at 10:32 am #2906
Ajay
KeymasterHi Masao
As we had discussed over the remote session support, the root cause of the error here is due to the coercion dot we noticed in D2XX Open VI after passing Open flags from List Devices VI. After replacing those VIs from example VIs it got resolved and we notice no errors through these VIs below
As a recommendation, I always suggest starting the work from prooved Example VI
Reference Example VI:
- Example_FT4222H_SPI_Master_Read.vi
- Example_FT4222H_SPI_Master_Write.vi
We noticed that there are no errors in example VI as in the screenshot below from our support session
There are application-level cleanups that might be required where proper handing of sessions (and closing wherever necessary).
Thanks
Ajay -
February 15, 2022 at 1:48 pm #2933
Masao
ParticipantTEST MESSAGE
-
February 15, 2022 at 2:10 pm #2936
Masao
ParticipantAlthough you notice about Coercion Dot, this dot has been introduced from your example, i.e. https://digiajay.com/forums/topic/error-ft4222_device_not_supported/#post-2870
I think you are obligated to find the cause of this dot appear in your code.
What do you think?
-
February 15, 2022 at 2:31 pm #2946
Ajay
KeymasterHi Masao,
You’re correct, the coercion dot exists in example VI as well. I just noticed it’s hidden and only becomes visible when I moved blue wires. I missed it in our remote session due to high resolution display on your side (& lower resolution display on myside).
However, we noticed in our session that example VI (SPI Master Write) works very well without any errors, and we even did the continuous run of the example VIs for repeatability for 10s of times.
I hope the change we did this morning is helpful to you, if the application doesn’t repeatedly run whiteout errors then I would recommend you to develop a simple plain VI with all required SPI write & read in linear sequence (without events or loops structures). I believe that would prove your concept before taking to the application. I strongly believe something on main application is bugging down to this issue.
Regards,
Ajay -
February 16, 2022 at 5:05 am #2957
Masao
ParticipantYou are right on the statement ” I strongly believe something on main application is bugging down to this issue.” and since Coercion Dot appears in your sample, your main application also has that capability. Even the program works yesterday, there is no assurance it would work tomorrow if we don’t know the real cause of it.
I believe that the Dot is the only clue to solve this issue, which is not acceptable from the software security view point.
Also I have another issue with the SPI protocol of the AAS33001. The protocol is one of standard and it uses duplex operation mainly.
So that I need SPIMaster_SingleReadWrite definitely. If you wouldn’t develop this function, I have to move another option.Regards,
Masao -
February 17, 2022 at 9:50 pm #2982
Ajay
KeymasterThe coercion has been there for quite a long time and it is not at all a trouble for many applications implemented so far.😊 I would suggest trying out with a simple VI (with a combination of examples from SPI read & write) to get a single read and write.
-
-
AuthorPosts
- You must be logged in to reply to this topic.