Teensy 4.1 (kint41) QMK support

[stapelberg]

Status

• milestone: light up LED
• milestone: print debug messages on the serial port
• milestone: light up a LED from ChibiOS
• milestone: print debug messages on the serial port from ChibiOS
• ChibiOS tests are passing successfully!
• milestone: USB stack used successfully from ChibiOS

USB

• the Teensy 4.1 has two USB 2.0 OTG controllers
• I’m trying to make controller USB1 (base address 0x402E0000) work (eval board: the USB port right next to the ethernet port, called “USB OTG” in the documentation, teensy 4.1: the main and only USB port)
• There are 5 different USB implementations I know of:
  1. NXP SDK (usb_device_dci.c)
     • supports KHCI (USB Full Speed)
     • supports EHCI (USB High speed, what the Teensy 4.1 uses)
     • supports LPC USB IP3511 FS
     • supports LPC USB IP3511 HS
  2. Paul Stoffregen’s official Arduino Teensy 4 core (usb.c)
     • Uses the EHCI interface, but also uses the teensy register macros, not NXP’s CMSIS.
  3. ChibiOS-Contrib Kinetis (hal_usb_lld.c)
     • The KINETIS hal_usb_lld.c uses the KHCI interface, which is not available on the Teensy 4.1 anymore.
     • Maybe we need to create a hal_usb_lld.c that uses the EHCI interface.
  4. The stack in libgreat is more readable/descriptive, but not 100% sure about correctness—might be better to prefer the NXP stack for now.
  5. Tamago’s USB stack: https://github.com/f-secure-foundry/tamago/tree/master/soc/imx6/usb

Building

• You need ChibiOS/ChibiOS@3249070 or newer (fixes the interrupt vector table alignment for teensy 4.1)
• My ChibiOS-Contrib WIP branch can be found at https://github.com/stapelberg/ChibiOS-Contrib/commits/teensy41

Wiring/testing

1. Connect a USB-to-serial adapter to teensy 4.1 pins G (GND), 16 (RX) and 17 (TX).
2. Build and flash the ChibiOS-Contrib teensy 4.1 demo:

   cd ChibiOS-Contrib/demos/MIMXRT1062/RT-TEENSY4_1
   make
   teensy-loader-cli -w -v --mcu=TEENSY40 build/ch.hex
   

3. After turning on the teensy 4.1, you should see debug messages on the serial console, followed by the ChibiOS test suites.

[stapelberg]

Status update: as of commit stapelberg/ChibiOS-Contrib@c6d4537, the ChibiOS serial usb device enumerates in my tests, and can be opened, but no data is sent/received over any endpoint but 0.

This line is where the device hangs: https://github.com/stapelberg/ChibiOS-Contrib/blob/c6d4537b6afbdb407f88526c0d5bdc72e7449c3a/os/hal/ports/MIMXRT1062/LLD/USBHSv1/hal_usb_lld.c#L172

Full log:

ISR
  setup ep=0
clear_out_queue
clear_out_queue, endpoint = 20002000, t = 00000000
_usb_ep0setup()
usb_lld_read_setup
bmRequestType = 00000000, bRequest = 00000009, wValue = 00000001, wIndex = 00000000, wLength = 00000000
usbcfg.c:usb_event(event=2)
usb_lld_init_endpoint(ep=1)
  OUT endpoint (RX enable), mode=2, maxsize=64
  IN endpoint (TX enable), mode=2, maxsize=64
usb_lld_init_endpoint(ep=2)
  IN endpoint (TX enable), mode=3, maxsize=16
usb_lld_start_out(ep=1)
usb_packet_receive(n=256)
usb_transfer_schedule(endpoint=20002080, transfer=2000327C, n=256, primebit=2, notify=1)

  ERROR: too many prime attempts, aborting
[…]

[stapelberg]

Status update: I managed to build a working firmware!

I pushed the various changes to GitHub for now, and will clean them up and send them upstream later as time permits.

You can try the current state using:

qmk clone -b kint41 kinx-project/qmk_firmware
qmk compile -kb kinesis/kint41 -km default
teensy-loader-cli -w -v --mcu=TEENSY40 .build/kinesis_kint41_default.hex

[stapelberg]

Status update: ChibiOS/ChibiOS-Contrib#246 is now cleaned up and ready for review, and all repositories have been updated based on the current QMK develop branch.

The instructions in #5 (comment) remain valid for trying out the firmware.

[mdempsky]

With ChibiOS/ChibiOS-Contrib#246 merged, what's the status of this issue? Is there still more to do for the 4.1 to be fully supported? Thanks.

[stapelberg]

With ChibiOS/ChibiOS-Contrib#246 merged, what's the status of this issue? Is there still more to do for the 4.1 to be fully supported? Thanks.

If you’re okay with building from my repository instead of QMK’s, then I consider the kint41 fully supported. I have been using a kint41 as my daily driver for weeks now, and have not noticed any issues. I know there is at least one other user without any issues.

QMK itself tracks their own branch of ChibiOS-Contrib which lags behind upstream, so for proper upstream support, my changes first need to make it into that branch. I want to ask QMK to cherry-pick, but wanted to finish some related work on keyboard latency to make sure I don’t ask prematurely (in case my work identifies other changes needed). Will probably ask next week or so.

[mdempsky]

SGTM, Teensy 4.1 ordered. Thanks!

[stapelberg]

I want to ask QMK to cherry-pick, but wanted to finish some related work on keyboard latency to make sure I don’t ask prematurely (in case my work identifies other changes needed)

Finished the latency work and asked QMK for the cherry-pick in qmk/qmk_firmware#12843

[tsharky]

Status update: I managed to build a working firmware!

I pushed the various changes to GitHub for now, and will clean them up and send them upstream later as time permits.

You can try the current state using:

qmk clone -b kint41 kinx-project/qmk_firmware
qmk compile -kb kinesis/kint41 -km default
teensy-loader-cli -w -v --mcu=TEENSY40 .build/kinesis_kint41_default.hex

Hey,
I can't compile kinesis boards from your fork on my windows machine.
Both 'kint41' and 'kint2pp' give me an unicode error.

Ψ Compiling keymap with make -j 1 kinesis/kint41:default


QMK Firmware 0.9.32
Making kinesis/kint41 with keymap default

ERROR 'charmap' codec can't decode byte 0x90 in position 1558: character maps to <undefined>
Traceback (most recent call last):
  File "C:/tools/qmk_msys/mingw64/lib/python3.8/site-packages/milc/milc.py", line 476, in __call__
    return self.__call__()
  File "C:/tools/qmk_msys/mingw64/lib/python3.8/site-packages/milc/milc.py", line 479, in __call__
    return self._subcommand(self)
  File "C:/Projects/qmk_firmware_kinx-project/lib/python/qmk/decorators.py", line 42, in wrapper
    return func(*args, **kwargs)
  File "C:/Projects/qmk_firmware_kinx-project/lib/python/qmk/decorators.py", line 85, in wrapper
    return func(*args, **kwargs)
  File "C:/Projects/qmk_firmware_kinx-project/lib/python/qmk/cli/generate/rules_mk.py", line 58, in generate_rules_mk
    kb_info_json = dotty(info_json(cli.config.generate_rules_mk.keyboard))
  File "C:/Projects/qmk_firmware_kinx-project/lib/python/qmk/info.py", line 57, in info_json
    info_data = merge_info_jsons(keyboard, info_data)
  File "C:/Projects/qmk_firmware_kinx-project/lib/python/qmk/info.py", line 476, in merge_info_jsons
    new_info_data = json_load(info_file)
  File "C:/Projects/qmk_firmware_kinx-project/lib/python/qmk/json_schema.py", line 18, in json_load
    return hjson.load(json_file.open())
  File "C:/tools/qmk_msys/mingw64/lib/python3.8/site-packages/hjson/__init__.py", line 117, in load
    return loads(fp.read(),
  File "c:/tools/qmk_msys/mingw64/lib/python3.8/encodings/cp1252.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x90 in position 1558: character maps to <undefined>
build_keyboard.mk:104: 'UnicodeDecodeError'>: No such file or directory
make[1]: *** No rule to make target ''UnicodeDecodeError'>'.  Stop.
Make finished with errors
make: *** [Makefile:530: kinesis/kint41:default] Error 1

I can compile 'kint2pp' from the official qmk project without issues.
Any chance you know how to fix it?

I'm new to Kinesis and QMK, so I have no clue where to look for differences between your fork and qmk.

Greetings!

[stapelberg]

I can compile 'kint2pp' from the official qmk project without issues.
Any chance you know how to fix it?

I rebased the kint41 branch on top of the current QMK development branch.

Possibly that fixes your problem (given that you say compiling QMK itself works).

Can you try cloning again and see if compilation now works?

If no, does compilation of kint36 work from the QMK upstream develop branch for you?

[cadusk]

My issue is related to pin names.
Before fetching latest, builds were working.

Now looks like pin names that don't match this criteria will fail:
pin[0] in 'ABCDEFGHIJK' and pin[1].isdigit()

Here's the output of the error message

Ψ Compiling keymap with make -j 1 kinesis/kint41:default


QMK Firmware 0.9.32
Making kinesis/kint41 with keymap default

⚠ Nonstandard pin format: LINE_PIN20
⚠ Nonstandard pin format: LINE_PIN21
☒ Invalid API data: kinesis/kint41: matrix_pins.cols.0: 'LINE_PIN20' is not valid under any of the given schemas
arm-none-eabi-gcc (Arch Repository) 11.1.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

⚠ Nonstandard pin format: LINE_PIN20
⚠ Nonstandard pin format: LINE_PIN21
☒ Invalid API data: kinesis/kint41: matrix_pins.cols.0: 'LINE_PIN20' is not valid under any of the given schemas
⚠ Nonstandard pin format: LINE_PIN20
⚠ Nonstandard pin format: LINE_PIN21
☒ Invalid API data: kinesis/kint41: matrix_pins.cols.0: 'LINE_PIN20' is not valid under any of the given schemas
⚠ Nonstandard pin format: LINE_PIN20
⚠ Nonstandard pin format: LINE_PIN21
☒ Invalid API data: kinesis/kint41: matrix_pins.cols.0: 'LINE_PIN20' is not valid under any of the given schemas
Compiling: keyboards/kinesis/kinesis.c                                                             <command-line>: fatal error: .build/obj_kinesis_kint41/src/info_config.h: No such file or directory
compilation terminated.
 [ERRORS]
 | 
 | 
 | 
make[1]: *** [tmk_core/rules.mk:436: .build/obj_kinesis_kint41_default/keyboards/kinesis/kinesis.o] Error 1
Make finished with errors
make: *** [Makefile:530: kinesis/kint41:default] Error 1

Also, builds of kint2pp and kint36 build just fine.

[stapelberg]

Sorry about that. Turns out clean builds were broken, but my working copy still had the required files lying around so I didn’t notice.

I pushed the old version for now, until I can properly fix the pin issue.