deskthority

Posted: **18 Nov 2016, 11:10**

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

Posted: **18 Nov 2016, 11:16**

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

Posted: **18 Nov 2016, 11:33**

matt3o wrote: 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.

Posted: **18 Nov 2016, 12:06**

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

Posted: **18 Nov 2016, 12:13**

Colde does not list kl27 as being supported though!

Posted: **18 Nov 2016, 12:14**

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

Posted: **18 Nov 2016, 12:16**

pomk wrote: Colde does not list kl27 as being supported though!

Damn, I did not looked that far...

Posted: **18 Nov 2016, 12:34**

edit: double post

Posted: **18 Nov 2016, 13:28**

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

Posted: **18 Nov 2016, 14:00**

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.

Posted: **30 Nov 2016, 07:12**

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

Posted: **30 Nov 2016, 08:01**

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.

Posted: **30 Nov 2016, 08:17**

LOL how did this project not make DTA 2016?

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

#dta2017

Posted: **30 Nov 2016, 11:29**

hasu wrote: 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.

Posted: **30 Nov 2016, 20:35**

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

Posted: **30 Nov 2016, 20:45**

tentator wrote: 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.

Posted: **30 Nov 2016, 20:48**

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

Posted: **30 Nov 2016, 21:59**

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

Posted: **30 Nov 2016, 22:10**

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?

Posted: **30 Nov 2016, 22:22**

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

Posted: **30 Nov 2016, 22:38**

it does not, it supports the device/peripheral mode

Posted: **30 Nov 2016, 23:51**

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.

Posted: **01 Dec 2016, 00:17**

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)

Posted: **01 Dec 2016, 02:01**

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.

Posted: **01 Dec 2016, 07:53**

pomk wrote: 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

Posted: **01 Dec 2016, 11:44**

pomk wrote: 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.

Posted: **01 Dec 2016, 11:56**

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

Posted: **01 Dec 2016, 12:06**

vvp wrote:
pomk wrote: 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.

Posted: **01 Dec 2016, 12:17**

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"?)

Posted: **01 Dec 2016, 12:24**

@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.

deskthority

Can we design the teensy alternative for keyboards?