Teensy 3.1 / MK20DX256VLH7 support

[flabbergast]

Repo organisation: I'm just happy you did the usb driver, so whatever works for you Maybe once the driver is more "complete", it could be moved to the main or contrib repo

So - I tried your USB_HID and USB_SERIAL examples, they work I also tried plugging it into my own "usb_hid" example I wrote originally for STM32, and it also works. However! It only does work with all the debug options in chconf.h disabled; once I enable CH_DBG_SYSTEM_STATE_CHECK they stop working properly. This happens both in my example and in your USB_SERIAL example. I couldn't find out where exactly the problem shows up - it's hard (for me) to hook up a debugger to a teensy (I think I would need to solder leads to MCU pins directly to do that), and so so far I just tried inserting some blink statements at various places. I think the trouble is happening in some interrupt callback, since the programs do get to the main loop, but don't last even one whole iteration (1sec), with all the shell code disabled.

EDIT: I'll try with MCHCK once I get home - that one has SWD pads, and the MCU is close enough to teensy 3.*, namely MK20DX128VLF5.

[flabbergast]

OK, so I didn't manage to successfully attach my ST-Link to mchck, but it turned out that the USB stack is the same on K20x and KL2x (modulo clock initialisation), so I've used my KL25Z freedom board to debug.

Here's a patch to the current RedoX's tsy_usb branch.

The main "bugs" with RedoX's usb_lld.c are a couple of forgotten OSAL_IRQ_EPILOGUEs, and a couple of locks/unlocks here and there. The point is that without the CH_DBG_ options these kind of fail gracefully, but with the debug enabled they get recorded (for instance the missing EPILOGUEs meant that ch.dbg.isr_cnt did not get decremented on finishing the interrupt, and consequently locking in the main thread failed). (Note that usb_transmit_packet() gets called at least once from a locked state by usb.c, and so to make things consistent, it should be called from a locked state always. Finally, the sdPut's also generate CH_DBG_ problems because they shouldn't be called from a lock and/or ISR.)

I have a Freedom KL26Z board on the way, so I intend to make sure that things run on this as well - which will effectively mean Teensy LC support.

[RedoX]

Nice !

I don't have enough time to work on this stuff theses days, but I will have a look at your patch on the evening.

Since the KL2x use the same USB module, it would also be cool to move the usb_lld to the lld/ folder (other modules may also be moved there I guess). Clock initialization is in the hal_lld so that's not a big deal anyway... but that reminds me I need to make a clean initialization for the K20x...

Thanks for the comments about the "bugs" (and yes, I kinda knew about the sdPut but on the Teensy, those were the only debugging tools I got... ).

Thanks!

[flabbergast]

Thanks!

Actually I did some of that work already here. Unfortunately (and I'm sorry about that!) I did not start from your branch, but from the official ChibiOS git and pulled your files over one-by-one (since I kind of wanted to learn how things work and what your changes were, and your branch/merge structure was a bit complicated). If you'd like, I can rebase the changes onto your branch and do a pull-request or something.

Mainly, the changes are:
- usb stack: redo the usb debug stuff so that it's "compatible" with CH_DBG_ options, since I quite like that you can check what USB transactions are going on. I did it using queues, but in principle it's worse for actual debugging of the stack, because printing is queued, since most of the stack is happening in ISR, so it should not do actual serial. Also there's a global debug #define which enables/disables this serial debugging. It should also make it easier to get rid of this code completely if required.
- move drivers that work on both KL2x and K20x into LLD (including the usb stack).
- move kinetis.h from devices common/.../K20x{5,7} to hal/ports/KINETIS/K20x/kinetis_registry.h and implement the choices using #defines, like it is done in the STM32 port.
- add some more guard preprocessor logic to kinetis drivers (e.g. if driver enabled but no peripheral attached, etc...)
- fix cfmconfig section placement with USE_LTO enabled (I reported this in another thread; this is kind of a serious thing since it can brick a teensy if cfmconfig optimized away).
- some more cleanup of #defines and such.

I did not make any changes to actual code.

I have a Freedom KL26Z board on the way, so I plan on making sure things work on this one as well, which should effectively mean Teensy LC support.

[Giovanni]

Having shared drivers, in general, is the way to go.

That would be a lot of work up front, because you have yo abstract all differences among devices, but then the project becomes more maintainable, less workload when adding new devices too.

Giovanni

[ohanssen]

BTW, I tried the ADC, the I2C master, the SPI master, and Serial. All appear to work fine
I still have to port I2C slave, which might be tricky (since the I2C slave implementation I currently have, outside of ChibiOS, relies on a tricky hack with PORTB_ISR), and USB, which might also be tricky (just because it's USB), but I like working with ChibiOS; thanks again for the work !
Cheers

Hi and thanks for the good work. I have tried the ADC using the demo in testhal/KINETIS/TEENSY3_1. It won't work.
The interrupt (IRQ handler in adc_lld.c) is never fired, it seems

I have tested using RedoX's tsy_usb branch (since I also need USB for my project).
Any tips?

Regards
Øyvind

[ohanssen]

BTW, I tried the ADC, the I2C master, the SPI master, and Serial. All appear to work fine
I still have to port I2C slave, which might be tricky (since the I2C slave implementation I currently have, outside of ChibiOS, relies on a tricky hack with PORTB_ISR), and USB, which might also be tricky (just because it's USB), but I like working with ChibiOS; thanks again for the work !
Cheers

Hi and thanks for the good work. I have tried the ADC using the demo in testhal/KINETIS/TEENSY3_1. It won't work.
The interrupt (IRQ handler in adc_lld.c) is never fired, it seems

Ok, I found it. In adc_llc.c the IRQ handler routine is declared like this
OSAL_IRQ_HANDLER(KINETIS_ADC0_IRC_VECTOR)

I changed it to
OSAL_IRQ_HANDLER(KINETIS_ADC0_IRQ_VECTOR)

And it works.
Regards
Øyvind

[utzig]

I just fixed those typos in the SVN. Interestingly in the SVN everything worked because the typos were consistent!

Cheers,
Fabio Utzig

[flabbergast]

Hey RedoX! Here's another fix for a bug in usb_lld.c (well the bug itself is the lines 380-382; the rest is harmless). That one's relatively hard to hit, but I did and it took me a while to find out what the problem was.

The gist is that the usb buffers are released twice for SETUP packets. This is usually not a problem, but I've been implementing a keyboard, and there's one SETUP request in the HID protocol (namely SET_REPORT), which follows up with a 1 byte of data on EP0/OUT. And this (reading that byte) wasn't working on your stack (but it did on the STM32 stack). Eventually it turned out that the bug is this.

[flabbergast]

So, I've worked some more on the kinetis code. Still no "new" code, but I cleaned up some things, moved drivers that could be moved to LLD, added more testhal demos, added some missing register definitions to CMSIS files, and things like that. The main point is that I've added Teensy LC and Freedom KL26Z boards, and some examples for them. (One "invasive" change compared to RedoX's code is renaming Teensy pin #defines, to make it easy to switch between various Teensies - the LC and 3.x have some pins routed to different MCU pins.)

I have a KL27Z breakout board in the pipeline, and plan on adding KL27Z support. That chip is pretty exciting for me, because it has a bootloader in ROM, and an official crystal-less USB.

Code on on github (kinetis branch). I know it's a lot of commits...