Sporadic GPIO problem Signal blocking

Martin Mayr
Martin Mayr New Member Posts: 54
Hello,

We used to switch two relays with the GPIO pins GPIO27 and GPIO29 ... for layout reasons I changed the pins to GPIO 22 and GPIO 23.

Since I did this layout change, we have randomly the GPIO22 switching on (signal then stays blocked even if its switched off per software !) without any call of any API function at the moment of the signal change.

We didn't see that problem before when using the other output pins (GPIO 27)

Is there anything special with this output pin ? (cause its connected to SPI_CS1 ???)

We work under Windows using the API functions ....

Is it a software issue, a firmware issue, a hardware bug ? Does this GPIO22 has a different behaviour the the earlier used GPIO27 ? Does it need pullup or pull down resistors or any other hardware treatment ?

Best regards

Martin

Comments

  • Jack
    Jack AAEON Posts: 16 mod
    Hi Sir,

    What's your current BIOS version?
    If you want to use GPIO22, please disable LPSS SPISupport item in BIOS first.

    Then you will see GPIO22 can be selected to Input or Output as GPIO27 in BIOS.


    Note:The BIOS screen did tell you related PIN number. Such as GPIO22 is PIN24 of HAT.

    Thanks,
    Jack
    1.jpg 55.5K
    a1.jpg 91.7K
    a2.jpg 100.7K
  • Martin Mayr
    Martin Mayr New Member Posts: 54
    Hello,

    first of all thanks for the information - unfortunately our BIOS seems not to have all items you have there ... our BIOS Verison is 2.17.1249
    the last two items of your screenshot are missing ... see screenshot ...
  • Martin Mayr
    Martin Mayr New Member Posts: 54
    Hello,

    we updated the BIOS Version and get now a bit confused between pin numbers in BIOS and in the documentation ... ?? Look at the attached image please and tell me if my reflexion is correct the number in the column of the WIKI seem 1 lower then in the BIOS ... is this an error in the BIOS or is this an error in the WIKI ???

    Best regards
  • Martin Mayr
    Martin Mayr New Member Posts: 54
    Hello, even after updating the BIOS and changing the values as described in the BIOS the problem reappeared again :(
    What can we do to localize this problem ? Is it a hardware problem ? Is it a firmware problem ? Is it a BIOS problem ?

    In my case we use the signal for outputting a light which when it stays on by error disturbs the video image for another measurement ... so I would need to understand how we can switch that light / signal off when it stays frozen on ...

    Is there a way per software to reinitialize the GPIO s even if a signal is frozen ??? (still in Windows 10 environment ...)

    Best regards ...
  • Jack
    Jack AAEON Posts: 16 mod
    Could you please provide WIKI link?
    Since you used GPIO27 had no problem before, I believe the PIN of GPIO27 is PIN38.
    We made attached DIO SDK, you can take a try.
  • Martin Mayr
    Martin Mayr New Member Posts: 54
    Hello
    The wiki page link is visible in the previously attached image ...
    But I will repeat it here : https://up-community.org/wiki/Pinout
    This page shows different Pin Numbers then those you provide in the BIOS ... But this is not the real problem for me the real problem is why is the output staying active even when switching it per software off ???
    Even when using your DIO.exe the once blocked output stays high when trying to switch it off ... the other outputs still switch correctly ....
  • Aling
    Aling Guest Posts: 561 admin
    We have noticed the problem need to be fixed by BIOS and new DIO SW kit.
    Now we are scheduling the test and will release a new BIOS and DIO SW kit.

    It might take 2-3 weeks due to the engineering resources at this moment. Thanks for your patience.
  • Martin Mayr
    Martin Mayr New Member Posts: 54
    Hello AlingWu,

    thanks for your response and please keep me updated when you have solved this problem and send us the link for the corrected BIOS as soon as available so we can do the tests here too ...
    Best regards

    Martin
  • Jack
    Jack AAEON Posts: 16 mod
    Hi Sir,

    WIKI defined the gpio from 0 to 27.
    However our BIOS defined gpio from 1 to 28.
    So, if you want to use GPIO22, please set gpio 23 in BIOS and connect your device on PIN26.
    I tried to set gpio 23 output low, I got 0V.
    You do not need to get into OS, and just set gpio 23 High/Low and use multimeter to measure PIN26 voltage is correct or not first.

    Note:I found the gpio22 in BIOS did have always high issue, I am checking with our BIOS RD about it.

    Please try gpio 23 in BIOS and connect your device on PIN26 to see if you can get right result.
  • Martin Mayr
    Martin Mayr New Member Posts: 54
    Hello again,

    The pins are used as you describe it and when using just from the BIOS they work fine since they work fine too but only for a few hours, when being used in the OS ... then sporadically the signal blocks in high level and stays high ... only switching off the Upboard allows to remove the problem and then it works again for a few hours ...
    The error seems to appear only with the Pin GPIO22 when using other pins the problem didn't appear yet ...

    Best regards and still need help about that issue
  • Jack
    Jack AAEON Posts: 16 mod
    Did you connect PIN26 of HAT or PIN24?
    Could you show me a photo about your connection with your device?

    Thanks.
  • Martin Mayr
    Martin Mayr New Member Posts: 54
  • Jack
    Jack AAEON Posts: 16 mod
    edited September 2017
    If I want to replicate the problem, I just need to set GPIO23 (PIN26) to output LOW in BIOS, then leave it for few hours, I will see PIN26 of HAT become High??
    Or how should I replicate the problem?

    Thanks.
  • Kedar Thakur
    Kedar Thakur New Member Posts: 2
    Was this problem solved... and if yes, how?

    We are facing the same problem working with windows using the AAEONIO.DLL in C++.
    In our case, the pins 19,21,23,24,26 and 37 are all showing the symptoms of latching, some high whereas some low.

    To reproduce the problem, we just have to keep turning the IOs ON and OFF cyclically and within a minute this problem will surface.
  • Jack
    Jack AAEON Posts: 16 mod
    Hi Sir,

    Sorry, the BIOS is not ready.
    Currently, we can provide WIN10 DIO SDK for your using.
    UP-CHT01_WIN_DIO_CPP_v20171031.rar is for C++ program.
    UP-CHT01_WIN_DIO_CS_v20171031.rar is for C sharp program.
    Please flash your BIOS back to UPC1BM0X and use our DIO SDK.
    You can download all files in below FTP.
    ftp://ae:aaeonae@dataex.aaeon.com.tw (Folder name: UP)

    Thanks,
    Jack
  • Martin Mayr
    Martin Mayr New Member Posts: 54
    Hello again, the proposed solution with the SDK is not really a good solution since these function don't work very fast - thats why we need to stay with the DLL functions being called from the C# through a wrapper functionality ... This way we have reaction times within a few ms and not within a few 100 ms ...
    So I redesigned my cards to use other pins but this is only a temporary solution for the problem ... which definitly must be fixed ... (not only for me but for all other users of UP boards.)
    The next issue will be PWM access now or alternatively I2C or SPI over Win10 to access through a PIC microcontroller to other functionality missing in Windows 10 drivers of the UP board - like e.g. analog output or analog input or PWM for motor drivers ....

    Hope to get some feedback about when which of these elements will be ready for Win10 (x64) Enterprise ....


    Best regards
  • Jack
    Jack AAEON Posts: 16 mod
    Hi Sir,

    If you application is running under OS, the OS SDK will cover the BIOS setting (It will nothing to do with BIOS, BIOS just initialed GPIO value in the beginning.).
    For SDK speed issue, I am asking S/W RD if there is any solution on it.

    Thanks.
  • Jack
    Jack AAEON Posts: 16 mod
    We did some experiment for this issue….Just use a loop to access DIO by SDK/EAPI interface on Up1 board, as below:
    [code]
    bFlag = TRUE;
    while (bFlag)
    {
    EApiGPIOSetLevel(EAPI_GPIO_GPIO_ID(6), 0xFFFFFFFF, TRUE);
    EApiGPIOSetLevel(EAPI_GPIO_GPIO_ID(6), 0xFFFFFFFF, FALSE);
    }

    [result]



    As you can see the result, the time interval is 0.189ms
    It seems to far from 100ms which you mentioned in Forum.

    Please provide more things about steps to reproducing or environment(such as how your code access the AAEON SDK\EAPI).