IC_TEENSY3_1 board config wakes from sleep successfully

[djfiander]

Description

The PJRC_TEENSY_3_1 board configuration will wake the computer when it's asleep, but then the keyboard wlll
lock up until it's unplugged and reconnected. Using the IC_TEENSY_3_1 board config fixes the problem. The computer will wake up, and the keyboard will continue to function.

Types of Changes

• Core
• [x ] Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

Checklist

• [ x] My code follows the code style of this project: C, Python
• [ x] I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• [ x] I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• [ x] I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[fauxpark]

This board is for the Input:Club keyboards, and has some Kiibohd-specific code. It should not be used for all Teensy boards.

[sigprof]

Looks like another problem caused by the “fix” in #10088 — that change needed to be effectively reverted for Input Club boards, and that was done in #12870, but the empty replacement for restart_usb_driver() was placed in a board file which apparently also has some code specific to the Input Club boards.

You can try removing BOARD = IC_TEENSY_3_1 and then adding this to <keyboard>.c:

void restart_usb_driver(USBDriver *usbp) {
    // Do nothing. Restarting the USB driver on these boards breaks it.
}

But this will fix the issue only for one specific keyboard.

Ideally the original problem that prompted the #10088 hotfix should be found and fixed properly. Apparently the original issue happens mostly on STM32F4x1 chips with USB-OTG, and there is an attempt to do a somewhat dirty fix just for those chips in #14988, but there does not seem to be any movement there for some time.

[djfiander]

I would really like it if both STM32 and NXP (teensy) boards both worked well, but digging that far into the code is way beyond me at this point. I'm just using the onekey as a test harness and framework for building my own keyboard(s).

If you've got suggestions for where to look to try to help develop the "real solution", just let me know. I'm not afraid of reading microcontroller manuals.

[djfiander]

So, I removed the "BOARD=", and copied the "restart_usb_driver" into my local board. It works properly on my FreeBSD box, but not on my Mac. The Mac recognizes that the device has connected, but typing doesn't do anything.

Looks like another problem caused by the “fix” in #10088 — that change needed to be effectively reverted for Input Club boards, and that was done in #12870, but the empty replacement for restart_usb_driver() was placed in a board file which apparently also has some code specific to the Input Club boards.

You can try removing BOARD = IC_TEENSY_3_1 and then adding this to <keyboard>.c:

void restart_usb_driver(USBDriver *usbp) {
    // Do nothing. Restarting the USB driver on these boards breaks it.
}

But this will fix the issue only for one specific keyboard.

Ideally the original problem that prompted the #10088 hotfix should be found and fixed properly. Apparently the original issue happens mostly on STM32F4x1 chips with USB-OTG, and there is an attempt to do a somewhat dirty fix just for those chips in #14988, but there does not seem to be any movement there for some time.

[sigprof]

So, I removed the "BOARD=", and copied the "restart_usb_driver" into my local board. It works properly on my FreeBSD box, but not on my Mac. The Mac recognizes that the device has connected, but typing doesn't do anything.

Is this behavior repeatable? Does the problem with Mac disappear when you are using BOARD = IC_TEENSY_3_1 instead of just overriding restart_usb_driver()?

You can try adding the other piece of code from IC_TEENSY_3_1 to your <keyboard>.c file (before the empty definition of restart_usb_driver() that you added), then do the same testing as before:

#define WDOG_TMROUTL *(volatile uint16_t *)0x40052012

void early_hardware_init_pre(void) {
    // This is a dirty hack and should only be used as a temporary fix until this
    // is upstreamed.
    while (WDOG_TMROUTL < 2)
        ;  // Must wait for WDOG timer if already running, before jumping
}

(There are no other differences between PJRC_TEENSY_3_1 and IC_TEENSY_3_1 — the initial GPIO setup for these board definitions is exactly the same.)

[djfiander]

Is this behavior repeatable? Does the problem with Mac disappear when you are using BOARD = IC_TEENSY_3_1 instead of just overriding restart_usb_driver()?

The keyboard works perfectly on the mac with the BOARD = IC_TEENSY_3_1 (which is why I submitted the PR: it worked on mac, BSD, and Linux).

You can try adding the other piece of code from IC_TEENSY_3_1 to your <keyboard>.c file (before the empty definition of restart_usb_driver() that you added), then do the same testing as before:

Hmm... Adding the code that you included does not fix the problem on the Mac. The keyboard still works elsewhere, but not on the Mac. I'll have to do some more digging later today.

[djfiander]

Bah! Ignore everything I said about it not working on my Mac. The problem was with the usb hub I use with my mac. So, moving JUST the restart_usb_driver() code into the onekey/teensy_32 works everywhere.

[fauxpark]

Suggested change

	//#include "config_common.h"
	// TODO: including this causes "error: expected identifier before '(' token" errors
	//#include "config_common.h"

[stale]

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

[stale]

Thank you for your contribution!
This pull request has been automatically closed because it has not had activity in the last 30 days. Please feel free to give a status update now, ping for review, or re-open when it's ready.