[Bug] Failed to use A9(VBUS sense) as matrix pins

[yulei]

Describe the Bug

While converting the NOAH keyboard(STM32F411) from custom matrix implementation to the standard matrix implementation. I found that the A9 pin can't be asserted to low. Normally the A9 pin was used for VBUS sense, and the macro BOARD_OTG_NOVBUSSENS can free this pin and let it used as an normal GPIO pin. After modified the following codes:

static void init_pins(void) {
  unselect_rows();
     for (uint8_t x = 0; x < MATRIX_COLS; x++) {
         setPinOutput(col_pins[x]);
         setPinInputHigh(col_pins[x]);
     }
 }

the matrix works as supposed. The above codes first turn the PIN to output, than switch back. I check the data sheet and googled, but can't find an explanation for this.

System Information

• Keyboard:
  • Revision (if applicable):
• Operating system:
• AVR GCC version:
• ARM GCC version:
• QMK Firmware version:
• Any keyboard related software installed?
  • [ ] AutoHotKey
  • [ ] Karabiner
  • [ ] Other:

Additional Context

[rgoulter]

I've been curious about this. I've been able to use A9 as GPIO input when using other keyboard firmware e.g. https://github.com/TeXitoi/keyberon. I wasn't the only one to try using A9 as an input pin, e.g. https://github.com/help-14/arisu-handwired/blob/aab80f7e8e5bfb3c79ab569bce105374f7478670/src/main.rs#L31 makes use of A9 as a pulled-up input.

In my case, I'm using the WeAct Studio STM32F401 and observe that A9 in input mode seems to not be pulled up even with the appropriate bit of GPIOA.PUPDR set, and/or always seems to read low when not connected to anything.

The simplest way to check this is messing with the onekey keyboard, and changing the pin definitions to

#define DIRECT_PINS { { A9 } }

(I didn't see any change from the suggested workaround of calling setPinOutput(pin); before setPinInputHigh(pin) in init_pins).

I observed that by adding an external pull-up resistor A9 pulling up to 3V3 (or 5V), then I could use A9 as input as expected.

I don't know why the internal pullup resistor doesn't seem to have an effect in this case, though.

[jiaxin96]

This problem occurs with the STM32F4 series (such as F401, F411) only, and it can be fixed by using a custom matrix scan method (e.g. https://github.com/Oh-My-Mechanical-Keyboard/qmk_firmware/blob/master/keyboards/yandrstudio/whiteMouse28T/f401/matrix.c , which is the way of my custom matrix scan method).

[zhaqian12]

By default,qmk define the macro BOARD_OTG_NOVBUSSENS to disable the VBUS sensing and make A9 normal.But,A9 still has an internal pulldown in practical application, it can not be a input pin with pull up in matrix.After browsing the code about the usb configuration in chibios (lib\chibios\os\hal\ports\STM32\LLD\OTGv1\stm32_otg.h:line417 and lib\chibios\os\hal\ports\STM32\LLD\OTGv1\hal_usb_lld.c:line43),I found the configuration of the GCCFG register for USB.By comparing the data sheets,I think not only NOVBUSSENS bit should set 1,but VBUSBSEN bit needs to be disabled(set zero) for A9 to work in STM32F2/F4 series.Then,I tested and succeeded.

[jiaxin96]

it's chibios bug. if define the macro BOARD_OTG_NOVBUSSENS, the "lib\chibios\os\hal\ports\STM32\LLD\OTGv1\hal_usb_lld.c:line43" should be fixed as #define GCCFG_INIT_VALUE (GCCFG_NOVBUSSENS | GCCFG_PWRDWN)

[drashna]

it's chibios bug. if define the macro BOARD_OTG_NOVBUSSENS, the "lib\chibios\os\hal\ports\STM32\LLD\OTGv1\hal_usb_lld.c:line43" should be fixed as #define GCCFG_INIT_VALUE (GCCFG_NOVBUSSENS | GCCFG_PWRDWN)

as this been patched upstream?

[h0jeZvgoxFepBQ2C]

oh my god, this has cost me 2 days of desperate tries (I'm a QMK newbie and building my first split keyboard in my life)... First i thought my soldering was wrong, but after flashing multiple devices and still have the same issue I had to search and found this issue. has this been fixed? Is there a workaround?

This should be at least mentioned somewhere in the readme....

[jiaxin96]

oh my god, this has cost me 2 days of desperate tries (I'm a QMK newbie and building my first split keyboard in my life)... First i thought my soldering was wrong, but after flashing multiple devices and still have the same issue I had to search and found this issue. has this been fixed? Is there a workaround?

This should be at least mentioned somewhere in the readme....

it's a bug in upstram ChibiOS repo. At present, you can only fix it by pach the relevant files youself. I have submitted a bug report for the upstream repo, but it has not been accepted in the new release.

http://forum.chibios.org/viewtopic.php?f=35&t=6226

[drashna]

This has been patched upstream and is currently included.