Error – FT4222_DEVICE_NOT_SUPPORTED

Home / Topic / Error – FT4222_DEVICE_NOT_SUPPORTED

Home Forums FTDI FT4222 LabVIEW Driver Discussions Error – FT4222_DEVICE_NOT_SUPPORTED

Viewing 9 reply threads
  • Author
    Posts
    • #2844
      MasaoMasao
      Participant

      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 7 months, 1 week ago by Ajayvignesh MVAjay. Reason: Updating the actual message received on email
    • #2856
      Ajayvignesh MVAjay
      Keymaster

      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

    • #2870
      Ajayvignesh MVAjay
      Keymaster

      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.

    • #2876
      MasaoMasao
      Participant

      Hi Ajay-san

      Unfortunately no difference happened.
      Revised code is below
      Revised VI

      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?

    • #2906
      Ajayvignesh MVAjay
      Keymaster

      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

    • #2933
      MasaoMasao
      Participant

      TEST MESSAGE

    • #2936
      MasaoMasao
      Participant

      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?

       

    • #2946
      Ajayvignesh MVAjay
      Keymaster

      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

    • #2957
      MasaoMasao
      Participant

      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

    • #2982
      Ajayvignesh MVAjay
      Keymaster

      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.

Viewing 9 reply threads
  • You must be logged in to reply to this topic.