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 2 years, 9 months ago by Ajay.
-
AuthorPosts
-
-
February 14, 2022 at 10:27 am #2844MasaoParticipant
Hello!
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 2 years, 9 months ago by Ajay. Reason: Updating the actual message received on email
-
February 14, 2022 at 12:16 pm #2856AjayKeymaster
Hi 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 #2870AjayKeymaster
Hi 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 #2876MasaoParticipant
Hi 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 #2906AjayKeymaster
Hi 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 #2933MasaoParticipant
TEST MESSAGE
-
February 15, 2022 at 2:10 pm #2936MasaoParticipant
Although 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 #2946AjayKeymaster
Hi 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 #2957MasaoParticipant
You 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 #2982AjayKeymaster
The 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.