Can we design the teensy alternative for keyboards?

[matt3o]

I mean as a dev environment. I was looking at NXP dev tools and was wondering if there was anything more streamlined

[pomk]

I like sublime text and files on disk. You can probably set up eclipse using some tutorial if you dont like the nxp environment.

[Ced67]

I mean as a dev environment. I was looking at NXP dev tools and was wondering if there was anything more streamlined

For personnal ARM development, I use CoIde, an Eclipse/gcc based environment that works out of the box.
The debugger I use is a J-Link probe.

[matt3o]

thanks Ced67! I was hoping something more cross-platform though

[pomk]

Colde does not list kl27 as being supported though!

[Ced67]

I too would have preferred to code on my linux box but I was too lazy at that moment to put together a complete toolchain with eclipse and gcc... I let me seduced by the easy way

[Ced67]

Colde does not list kl27 as being supported though!

Damn, I did not looked that far...

[pomk]

edit: double post

[matt3o]

sublime text, do you mean you develop "bare metal" without any libraries and aids?

[pomk]

Yes, at home and at work. Of course for hobby projects I do make use of the APIs made by the chip developer, at work it varies quite a bit.

[hasu]

Got ELF boards the other day! Thank you, matt3o.
Looks nice, yay.


Unfortuately, I've had an issue that USB interface of ROM bootloader is likely to be closed quickly just after it starts up and I cannot interact with the bootloader. That is, I cannot flash firmware via USB in reliable way. I found I have to have pull-up/down resistors on some pins to resolve this issue but was not sure how this works or whehter this is correct soltuion.

Today I just discovered this Kinetis chip errata in the end, see 'e9457'. darn, wasted full of my day for this
http://www.nxp.com/assets/documents/dat ... _1N71K.pdf

e9457:
Kinetis Flashloader/ ROM Bootloader: The peripheral auto-detect code in
bootloader can falsely detect presence of SPI host causing non-responsive
bootloader

Description:
During the active peripheral detection process, the bootloader can interpret spurious data on
the SPI peripheral as valid data. The spurious data causes the bootloader to shutdown all
peripherals except the “falsely detected" SPI and enter the command phase loop using the
SPI. After the bootloader enters the command phase loop using the SPI, the other peripherals
are ignored, so the desired peripheral is no longer active.
The bootloader will not falsely detect activity on the I2C, UART, or USB interfaces, so only the
SPI interface is affected.

Workaround:
Ensure that there is an external pull-up on the SPI chip-select pin or that the pin is driven high.
This will prevent the bootloader from seeing spurious data due to activity on the SPI clock pin.

OK. This is still bummer, we may have to ditch a pin to resolve this


I wrote simple code for ELF that LED blinks at startup and indicates capslock state, push button(bl) registers 'a' on host. Attached binary file, you can use it if you like. Ah, I don't know how to post hex file on DT
https://github.com/tmk/tmk_keyboard/tre ... 27z_onekey

[matt3o]

this is great hasu! thanks for your help!

I indeed had the same issue on Linux. It's incredibly weird though, the other day I connected the elf board to a windows laptop (it's actually a tablet/laptop convertible) and blhost was able to connect to the bootloader very reliably. So I can probably test your "onekey" firmware.

Might that be an interference thing? I remember I had a similar problem with a completely different project where connecting to a battery powered (compared to a wall-powered) laptop solved the issue.

[Wodan]

LOL how did this project not make DTA 2016?

I ban you from next years DTA team matt3o ... somehow.

#dta2017

[vvp]

OK. This is still bummer, we may have to ditch a pin to resolve this

I would say keep the pin even when it has a hard pull-up connected. A pin with a pull up can be still useful for many things. People may prefer not to use it but it is a pain when one pin is missing and one needs to solder a wire on an SMD resistor in the middle of a PCB. Maybe the pin can be made internal only (instead at the edge of the PCB) so that people do not tend to use it.

[tentator]

Wow matt3o! How could I miss this thread so far?? Geniale!!
I can enroll for the beta if you have one to send me.. I'm quite skilled firmware and driver developer
How many gpio does it have? Looks promising. . What's the price of the chip when bought bulk?
I immagine target would be to have a bootloader and then run tmk for instance? Does it have vusb o chip has also usb host support?

Tent:wq

[matt3o]

Wow matt3o! How could I miss this thread so far?? Geniale!!
I can enroll for the beta if you have one to send me.. I'm quite skilled firmware and driver developer
How many gpio does it have? Looks promising. . What's the price of the chip when bought bulk?
I immagine target would be to have a bootloader and then run tmk for instance? Does it have vusb o chip has also usb host support?
Tent:wq

surething! PM me your address. Yes, the plan would be to run TMK on it but also haata's firmware if possible. it's not vusb! The price I guess could go around $12-15 but I really haven't checked it yet, we have to solve the bootloader thing first.

[Findecanor]

BTW, which MCU are you using, again?
Once the specs are set in stone then please create an article about it in the Wiki.

[pomk]

It is the KL27 with 256kb of flash.
http://cache.freescale.com/files/32bit/ ... pdf?fasp=1

[tentator]

Nice one! Plenty of flash! What usb port type is that?
Is the bootloader button enabling the flash as mass storage space or what is the idea of it?

[tentator]

Hang on.. why in the spec it says that the chip does not support usb host mode??

[pomk]

it does not, it supports the device/peripheral mode

[pomk]

Hmm, regarding the SPI hassle, it can be disabled when writing the first image on the chip, by writing 0x8 to flash address 0x3C0 + 0x10 (see reference manual p. 178). Note that the rest of the configuration data has to be valid as well for that to take effect. Thus, should we be able to get the boards pre-flashed by some (other) means, we could opt to keep the troublesome SPI pins as is.
One other option would be to have a pull-up resistor in place, but put a 'cut trace' disable on it, so that people who have flashed their first firmware to the board can then effectively remove the pullup.

I managed to get as far as using blhost and kinetis flash tool to check the device properties, but did not have enough time to try to compile and load what hasu has made.

[tentator]

ah ok, peripheral mode makes sense.
so idea is to disable spi in bootloader, yes.. but only if you manage to flash it at all in the first place.. did you manage to do it because it is like randomly sometimes it works and sometimes not?

PS: are you guys using the NxP bootloader or the Freescale? (NXP_Kinetis_Bootloader_2.0.0 package)

[pomk]

One method is to program the chips before soldering using a solderless chip socket and supporting electronics (expensive). A cheaper solution, which is possible because the swd pins are grouped on one side, would be to use a card edge connector to temporally attach the board to a swd debugger and use that to install the initial firmware.

[matt3o]

One other option would be to have a pull-up resistor in place, but put a 'cut trace' disable on it, so that people who have flashed their first firmware to the board can then effectively remove the pullup.

this is probably the best solution. I don't think it would impact too much on pricing and it's pretty user-friendly

[vvp]

One other option would be to have a pull-up resistor in place, but put a 'cut trace' disable on it, so that people who have flashed their first firmware to the board can then effectively remove the pullup.

Maybe rather a solder jumper connected by default instead of 'cut trace'. Or both.

[Wodan]

Full size jumpers are huge and usually through hole. Through hole stuff is expensive to mass produce ... so I was told

[pomk]

One other option would be to have a pull-up resistor in place, but put a 'cut trace' disable on it, so that people who have flashed their first firmware to the board can then effectively remove the pullup.

Maybe rather a solder jumper connected by default instead of 'cut trace'. Or both.

If we remove solder mask on the 'cut trace' location, it can easily be soldered together if necessary. Removing solder however is always more complicated and a more risk prone operation when done by a novice. Also I'm not familiar as to how the paste layer should be shaped around the solder jumper in order to reliably close it in production.

[tentator]

what would be the issue if we keep the pullup?

or what would be the issue if we disable spi in the bootloader/flash as default/factory? (is this not possible because the chips arrive "empty"?)

[vvp]

@pomk: Good idea. Removing solder mas on the cut location will do. And maybe making the trace a bit thicker (if somebody would wont to reconect it with solder).

@tentator: In many use cases the pull-up does not matter if it stays there. It will just consume a bit more power. Most people will be able to leave it there and not scratch anything.