UP Squared Pro 7000 (UPN-ADLN01) – HAT GPIO inputs never change in software on Windows, multimeter c

fahmidk
fahmidk New Member Posts: 2 ✭
edited September 24 in UP Squared Pro 7000 Windows

Hi all,

I'm trying to read a push button on the 40-pin HAT of a UP Squared Pro 7000 (UPN-ADLN01) under Windows. The signal is correct on the pin (confirmed with a multimeter), but no software layer ever sees it change. The same C# code worked on another UP board (UP Xtreme i14).

Setup

  • Board: UPN-ADLN01, BIOS [BIOS version]
  • OS: Win 11 IOT, 64-bit
  • UP Framework 24.09.10 (clean install; drivers: ACPI 11.5.15.822, Service 11.5.15.822, LED 11.6.14.247)
  • BIOS HAT configuration: the pin is set to GPIO, direction Input

Circuit (active-high)

  • Pin 1 (3.3V) -> button -> pin 7
  • 10kΩ from pin 7 -> pin 9 (GND)
  • Multimeter on pin 7: ~0V released, ~3.3V pressed. Also tried pin 15 with the same result.

What I've tested (all read-only while pressing the button)
1. EAPI directly (aaeonEAPI.dll, EApiGPIOGetLevel) polling all IDs 0–39, using ID = physical pin − 1. No ID changes on press.
2. UpNetlib UPGpioProvider + Windows.Devices.Gpio (.NET), opening physical pin − 1 as Input. Level never changes. InputPullUp is rejected with "Only support Output or Input Mode".
3. AAEON's UpNetGpioTestTool from win-demo-apps: pin 6 (= physical 7) reads Low, including while the button is held.

Software vs meter doesn't match on other pins either:

  • Pin 29: software HIGH, meter 0.01V
  • Pin 7 (button held): software LOW, meter 3.3V

The mapping itself looks right: EApiGPIOGetDirection fails only on the alt-function pins (3, 5, 8, 10, 11, 19, 21, 23, 24, 27, 28), which matches the header layout. So it looks like the header side isn't being passed through to the SoC for inputs.

I also cleaned up a mixed SDK install (24.09.10 and 24.12.27 had been installed over each other, and the 24.12.27 ACPI driver was left behind). The behaviour is the same on the clean 24.09.10 stack.

I found the linux-gpio thread "Up Squared Pro 7000 (UPN-ADLN01) broken BIOS?", where HAT pins were owned by ACPI/locked by the BIOS, and AAEON shared an engineering BIOS (UNASAM36) that fixed inputs on Linux.

Questions
1. Is this the same BIOS issue, and does that fix also apply to Windows?
3. Is there any other BIOS setting needed beyond GPIO + Input for the pin?
4. Which UP Framework version is recommended for this board? 24.09.10 doesn't include UpNetlib.dll, while 24.12.27 did.
5. Any recommendations in general?

Happy to run any tests or send logs. Thanks!

Privacy Policy