Can we design the teensy alternative for keyboards?

pomk · 05 Oct 2016, 14:33

I guess that the risk is just in setting the security flags correctly in the binary file?

I'm not sure if we can have our own bootloader flashed to ROM without placing a stupid large order to NXP. We could build a smaller one on top of it in flash though, if that is what you meant.

matt3o · 05 Oct 2016, 14:44

have to check with the manufacturer about that

pomk · 05 Oct 2016, 16:21

I'm fairly certain that haata's kiibohd bootloader resides in the flash area as well. The first 4k to be exact. And the manufacturer can just give the boards as is. The default bootloader (which is in ROM) can be used to load haata's one in as required.

The K20 processors kiibohd has run before do not have a ROM bootloader in place, but rather rely on flash bootloaders completely and can be bricked as well if given wrong flash security settings as part of the binary.

matt3o · 05 Oct 2016, 16:54

got it

hasu · 05 Oct 2016, 23:31

pomk wrote: ↑I guess that the risk is just in setting the security flags correctly in the binary file?

IIRC, ROM Bootloader can masserase and recover from FSEC corruption as long as you can access it. But ROM Bootloader can also change Bootloader Configuration Area (BCA) and corrupted BCA can prevent you from getting access ROM Bootloader. "Brick" I meant is this situation. I had to use SWD programmer to recover BCA.

ROM Bootloader allows users even to update Flash Bootloader themselve, this would be great if they are just careful with good instruction when using it. And it is safer option that users usually use Falsh Bootloader to update keyboard firmware.

IIRC, Haata's kiibohd bootloader writes firmware elaborately keeping FSEC address untouched so that users cannot brick their keyboard. Our bootloader will have to keep away from BCA in addition to FSEC.

pomk · 06 Oct 2016, 09:12

So you suggest we have a bootloader in flash as is used in kiibohd and use the ROM bootloader as an additional backup bootloader? That would seem like a quite safe option.

hasu · 07 Oct 2016, 12:19

Maybe I'm too anxious, after check-in app note again I think it is too difficult to config BCA accidentally. And people in the loop of keyboard community like DT, GH and r/mk are not kind of consumers. We can be optimists for initial batches at least.

Though, someone should check documents of kinetis bootloader and tool before we decide it.

Sent from my Nexus 5X

pomk · 07 Oct 2016, 13:49

The kinetis bootloader tool is a bit tedious to use. It comes only as a command line tool and you have to type at least 4 phrases every time you wish to upload a new firmware. It's still pretty easy, but the kiibohd bootloader is easier. You can of course use both! The BL button invokes the ROM bootloader (press and hold while plugging the USB cable), while the RESET button invokes the flash bootloader (similarly to how it happens on white fox etc.), if present.

matt3o · 24 Oct 2016, 13:06

boards are in production... ETA 2-3 weeks

Wilkie · 25 Oct 2016, 17:06

matt3o wrote: ↑boards are in production... ETA 2-3 weeks

Great work! And now the Deskthority Awards need a new category, Best Community Project.

matt3o · 26 Oct 2016, 08:19

These would be the gerber files as modified by the fab for production.

pomk is already checking them, but I guess an additional pair of eyes wouldn't hurt.

vsev · 26 Oct 2016, 09:53

Didn't took time to read from beginning, would that thing be ready to run whatever keyboard pcb to plug in through somehow specific code ?
Great project indeed !

matt3o · 02 Nov 2016, 17:54

samples are ready! will be shipped to me soon

Ray · 02 Nov 2016, 18:11

vsev wrote: ↑Didn't took time to read from beginning, would that thing be ready to run whatever keyboard pcb to plug in through somehow specific code ?
Great project indeed !

"that thing" is hardware in the first place. It will run firmware, not keyboard pcbs.
If you have specific code, good for you. Of course they had the usual community firmware in their mind when choosing chips, so it won't be too hard to drive normal keyboard matices.

@matt3o:
great, when do you take orders for the first group buy?

matt3o · 02 Nov 2016, 18:32

as soon as the prototypes are confirmed working

matt3o · 15 Nov 2016, 08:11

Does everything look fine to you?

: final assembling pic to confirm.jpg (487.16 KiB) Viewed 5511 times

pandp · 15 Nov 2016, 08:47

+1
Waiting for GB

pomk · 15 Nov 2016, 08:59

There could be a bit more solder on the connectors legs, but that is pretty minor and quite possibly just a cosmetic thing. Nothing else I can see at the moment.

beltet · 15 Nov 2016, 12:53

Stunning!

EDIT:
Can you link a datasheet of the chip? Would be nice to read through it.

pandp · 15 Nov 2016, 12:58

BTW, is it works?

MediocreBadGuy23 · 15 Nov 2016, 13:42

Been watching this thread for a while now and it's exciting to see this come together. Looks awesome!

matt3o · 15 Nov 2016, 14:14

I have a very limited quantity of samples. I will send a couple to hasu, pomk, flabbergast and haata possibly.

If you feel skillful enough to beta test this first batch (knowing that you will likely need to tinker with bootloader and firmware) contact me directly. Please note this might not be the final product, you better wait for the second wave if you want a ready-to-use board.

cookie · 15 Nov 2016, 15:04

Sadly, my skills are below what is necessary to actually work with the board. I'd love to start fiddeling around with hardware programming but I have no clue

Edit: If you have a spare controller I'd love to try it out and I will send it back to you if needed.

matt3o · 17 Nov 2016, 14:05

They are finally here. I had no time yet to play with it but I get a weird output by dmesg

Code: Select all

[34422.565667] usb 1-2: new full-speed USB device number 14 using xhci_hcd
[34422.700298] hid-generic 0003:15A2:0073.000E: hiddev0,hidraw7: USB HID v1.00 Device [Freescale Semiconductor Inc. Kinetis Bootloader] on usb-0000:00:14.0-2/input0
[34424.411211] usb 1-2: USB disconnect, device number 14

it basically connects and immediately disconnects, but like I said, I just unboxed them. I'll verify that everything is working and then ship to interested parties!

pomk · 17 Nov 2016, 15:09

I think that is already a pretty good sign that the board itself at least functions, on some level, as it stays active for a pretty long time considering that it manages to do a handshake with the computer. Have you tried pressing the bl and reset buttons simultaneously when the board is plugged in? First push bl, then reset, then raise reset and last raise bl.

matt3o · 17 Nov 2016, 15:28

I tried to reset but it just disconnects after few moments, but I have a feeling this is normal for a firmware free board. we have an LED, right? On which pin is it again? I can try to burn a very simple blinking program.

pomk · 17 Nov 2016, 15:59

the led should be lit if PTD7 is high.

matt3o · 18 Nov 2016, 10:56

still fighting with the development environment

What do you guys use?

pandp · 18 Nov 2016, 10:59

Teensy Loader, Command Line
https://www.pjrc.com/teensy/loader_cli.html
or
https://www.pjrc.com/teensy/loader.html

pomk · 18 Nov 2016, 11:03

pandp wrote: ↑Teensy Loader, Command Line
https://www.pjrc.com/teensy/loader_cli.html
or
https://www.pjrc.com/teensy/loader.html

This is not a teensy

matt3o wrote: ↑still fighting with the development environment What do you guys use?

I have not set up a compilation environment for this board yet, but I prefer a plain arm-gcc setup.
You will probably have to follow one tutorial to set up the compilation environment & compile some example program and another one to use the rom bootloader for flashing. You should take extra care when setting the 'flash configuration area', which is part of the program binary you upload to flash. If the 'flash configuration area' is not set properly, it is possible to brick the chip so that you need a swd debugger to un-brick it.