cpu: RIOT port for Freescale Kinetis CPUs

[jnohlgard]

Tracker to coordinate porting efforts for Freescale Kinetis CPUs #2265.

It was discussed on the riot-devel mailing list that it would be useful to have a tracking issue for coordinating efforts on Kinetis platforms.

Pull requests related to Kinetis platforms:

• Support for Freescale Kinetis MCUs, kinetis_common #2265 cpu/kinetis_common - merged 2015-02-05
  • RIOT port for the MKW22D512 SiP and Phytec PBA-D-01 PhyWave Evaluations-Board #2059 cpu/kw2x, boards/pba-d-01-kw2x - merged 2015-05-15
  • Add support for Kinetis K60 CPUs and Eistec Mulle IoT board #2282 cpu/k60, boards/mulle - merged 2015-04-10
  • Support for Freescale K64F MCU and FRDM-K64F Board #3126 cpu/k64f, boards/frdm-k64f - merged 2015-07-02

Porting progress:

• basic file structure
  • Merge two Kinetis trees (k60 and mkw2x) @gebart
• CMSIS PAL headers
  • MK60D10 @gebart Taken from Freescale Kinetis SDK 1.1.0, 3-c BSD license
  • MK60DZ10 @gebart Found in Keil uVision IDE, needs a redistribution license from Freescale Copying is OK
  • MKW22D5 @jfischer-phytec-iot
    Freescale_~~ Copying is OK
• linker scripts kinetis: Share ldscripts between CPUs #2393
  • MK60DN512VLL10 @gebart
  • MK60DN256ZVLL10 Implemented, needs review @gebart
  • MKW2xDxxx @jfischer-phytec-iot
• Startup code
  • C-library initialization (tightly coupled with the linker script)
    • K60 (both) Implemented, needs review @gebart
    • KW2x @jfischer-phytec-iot
  • Interrupt vector definition
    • MK60D10 needs review @gebart
    • MK60DZ10 needs review @gebart
    • MKW2xDxxx @jfischer-phytec-iot
    • Shared names between CPUs for ISR function definitions where applicable @gebart
  • Watchdog disable during boot
    • K60 (both) needs review @gebart
    • KW2x @jfischer-phytec-iot
• peripheral drivers
  • UART Implemented, needs review @gebart
  • hwtimer (LPTMR) Implemented, needs review @jfischer-phytec-iot
  • other timers (PIT) Implemented, needs review
  • GPIO Implemented, needs review @jfischer-phytec-iot
  • cpuid, depends on MCU, Implemented for mkw2x and mkw01z128, needs review @jfischer-phytec-iot
  • SPI Implemented, needs review @jfischer-phytec-iot
  • I2C Implemented, needs review @jfischer-phytec-iot
  • rtt, kinetis: Refactor RTC into RTT, add RTC wrapper. #2406
  • rtc , needs review @jfischer-phytec-iot* -> kinetis: Refactor RTC into RTT, add RTC wrapper. #2406
  • pwm (FTM) Implemented, needs review @jfischer-phytec-iot
  • adc Implemented, needs review @jfischer-phytec-iot
  • random number generator (RNGA), Implemented needs review @jfischer-phytec-iot
  • random number generator (RNGB), @gebart
  • Multipurpose Clock Generator (MCG) , Implemented needs review @jfischer-phytec-iot
  • Watchdog (WDOG)
  • Low Power Mode, kinetis: Add LPM implementation #2605, needs review @gebart
• Boards using Kinetis CPUs
  • Mulle @gebart
    • wiki documentation @gebart
  • phyWAVE-KW22 @jfischer-phytec-iot
    • wiki documentation @jremmert-phytec-iot
• C++-support (generalized, see C++ on the boards #1323, c++: Define some support functions required by GCC #3107)

[haukepetersen]

nice, I can enable the c++ support once you initial PRs are merged.

[jfischer-no]

Startup code depends on MCU (resp. SiP).

[jnohlgard]

Maybe not the most urgent question, but still:

Should the cpu directory for the Kinetis CPUs be named mkw2x, mk60 etc. or kw2x, k60 etc.?

The marking on the package begins with an M, but the CPU series according to Freescale's product catalog is Kinetis Kxx.

Update: M is actually the Qualification status according to the data sheet: P for prerelease, M for general market

[jfischer-no]

@gebart
Our current status (unfortunately, something went in the background):

• I've looked at your hwtimer implementation, but I do not quite understand it. I have completed our hwtimer implementation. It can actually be realized only with lptmr, the PIT will not run in low power modes. As your implementation, it simulates a 32-bit timer. You can set one of four different clock sources. We have tested it with RTC clock (32768Hz) and LPO clock (1kHz). It works quite well, except that vtimer is not working properly after some time. I suspect the vtimer has a bug that shows up when HWTIMER_SPEED is less 1MHz.
• We have already moved all peripheral drivers to kinetis_common. RIOT port for the MKW22D512 SiP and Phytec PBA-D-01 PhyWave Evaluations-Board #2059

We have completed the porting on kw01z128, but not tested everything. Both ports (kw0x and kw2x) use kinetis_common and it seems to work with some minor difficulties. First cognitions of it are:

• Startup code and linker script depends on MCU
• Interrupt tables are different
• WDT is implemented in different kind
• There are two RNG implementations (RNGA and RNGB)
• There are several different implementations of UART (kw01z128 has two slightly different, UART0 and uart)

How far are you with k60? How can we merge it all? I would prefer if it were so far in mid-January, the end of February is the Embedded World ...

[jnohlgard]

@jfischer-phytec-iot
I only recently had any time to spend on this. I have updated my branch to make use of your kinetis_common peripherals, I discarded most of my older work. I also started using your hwtimer implementation, which seem to do mostly the same thing as mine was intended to do, but it seemed more mature and easier to follow.

Regarding the RNG implementations, we are in the same situation, the MK60DZ10 uses one implementation, the MK60D10 (no Z) uses the other implementation. There are other differences as well. In our Contiki port we decided to introduce a #define constant for the board serial number, which can then be used to pick between the two different versions. There are quite a lot of differences between the two in clocking set up and power control (LPM).

I can make an attempt to fix up my K60 port later during this week and rebase it on your tree to have a combined tree.

I also have some code in the Contiki port for computing SPI timing parameters and UART timing parameters automatically based on core clock which makes the configuration more robust and also more flexible. The API of the SPI and UART drivers in our Contiki port is designed for ease of use, you only supply the desired baud rate and timings and the driver computes the optimal settings. This makes it easier to work with dynamic core clocking (use a higher speed when doing some computations, then scale down)

The Contiki stuff is BSD licensed, but I am the author and Eistec is the copyright owner and will re-release whatever we decide to reuse in RIOT under LGPL to integrate with the rest of the tree.

I do not think it is necessary to unify the initial startup and interrupt vector code for the Kinetis ports at this point in time, it is better to do a refactoring of this later in my opinion. The interrupt handler names can be unified in order to make it easier to move between the platforms.

Once the core functionality is there and the SPI driver is running on the K60 I want to focus on getting the AT86RF212 on my board working, hopefully it will "just work", but I know that @thomaseichinger is doing some major refactoring of the rf23x driver.

[thomaseichinger]

@gebart Looking at the registers and operating modes, the current at86rf231 should work out of the box with your radio. Because I'm curious, do you have an at86rf212 or at86rf212b.

[jfischer-no]

@gebart I want to change the todo list. I would remove:

• CMSIS PAL headers
• linker scripts
• Startup code

Is it ok for you?

[jnohlgard]

@thomaseichinger I have the AT86RF212B

@jfischer-phytec-iot CMSIS PAL headers are done, I guess. The MKW22D5.h header looks like a mashup between the older non-CMSIS headers from Freescale and the newer CMSIS-compatible ones. Using CMSIS headers makes many things alot easier when writing code, and the code will be more readable, than with the Freescale non-CMSIS headers.

Startup code is working fine for MK60DxxxxVLL10, have not yet ported to MK60DxxxxZVLL10.

Linker scripts seem OK, though only works with BFD linker, broken with gold (required for LTO)

[jfischer-no]

@gebart Since kinetis_common shold house only the peripheral driver (for the beginning), I thought, we can remove these sub-items completely from the todo list.
MKW22D5.h is the newest CMSIS compliant header file from Freescale.

[jfischer-no]

@gebart There is a own PR #2265 for kinetis_common now.

[jnohlgard]

@jfischer-phytec-iot I think I found out why you had to specify everything related to RNGA manually, the header MKW22D5.h is misnamed, it is actually the MK22xxxx (no W), which means that it is a completely different set of modules. I have opened a PR against your WIP branch for the kw2x, but still missing is some system functions found in system_MKW22D5.{c,h}

[jfischer-no]

@gebart The name of the header is correct, the SiP MKW22D512 for example, consists of Cortex M4 and the Modem. The headers are from our FAE and already have the appropriate license.

system_MKW22D5.{c,h}: We do not want to use it, the code is horrible, I'm on the driver for MCG, I will publish it on Monday.

[jnohlgard]

@jfischer-phytec-iot I understand what you mean with the code being horrible in system_xxxxx.c. I actually adapted the functions in the file to my own use in the K60 port to fit the use case. I adapted the SystemCoreClockUpdate function to work with my CPUs and use the global variables SystemXxxClock (Sys, Bus, Core, Flash) to keep track of the current clock frequency, instead of a compiler macro (F_BUS etc.). This means that the module clock passed to e.g. uart_init is correct for the current running clock configuration as long as SystemCoreClockUpdate was called after setting the clocks.

[felinira]

Regarding 'Watchdog disable during boot': Is RIOT supposed to work with watchdog? I just disable it right now but it could be desirable for some applications to switch it back on after booting. Would it be a good idea to add watchdog APIs to kinetis_common (or even to riot itself) that only have to be implemented or would that be overkill right now?

[OlegHahm]

@haukepetersen, didn't you have an opinion concerninc watchdogs in RIOT?

RIOT now (scnr) we don't make use of a watchdog for any architecture afaik.

[jfischer-no]

The KL (Cortex-M0) devices have a different WDT than K Devices (Cortex-M4). I think for now we have enough to do. I would like to see kinetis_common mainline until the end of January.

[haukepetersen]

@OlegHahm Yes, I have some concerns, tickless scheduling and watchdogs are not best friends, as watchdogs need to be refreshed periodically... But if RIOT is used in a non-low-energy context (or if there are periodic threads running), a watchdog could well be used. But these are just not our default IoT-scenarios - so I did not want to spend time on it. I wouldn't object a watchdog driver API in RIOT - all I would object to is to enable watchdogs per default.

[jfischer-no]

@gebart @Farthen I finisched my initial support for MCG.
https://github.com/jfischer-phytec-iot/RIOT/commit/2e4a450f338e05bb2ac6353ee10c522d36a7c86c

I have tested all MCG modes (FEI, FEE, PBE, PEE ...) with crystal or external clock on two MCUs (Cortex-M0 and Cortex-M4). Please look for examples in mcg.h

[felinira]

Looks great, will test the FEI soon. I currently can't test the external clock as my module does not have any installed right now and I would need to start soldering… I may be able to do this in a few weeks or so.

Just one question: My board's 'original' (open source) firmware enables the DMX32 bit on FEI even though it is not recommended. It works great for me as the internal oscillator is actually somewhat calibrated. I don't really know if this should be an option as it could potentially damage hardware but at least people using my board have probably already been exposed to this risk? I'm not really sure if the disclaimer in the reference manual about enabling DMX32 is a real concern or just a safety measurement from Freescale to not be sued.

For the clock mode switching: You could maybe replace the while loops with loops that automatically end after some time and just fail or panic for easier debugging if some hardware configuration is wrong. Right now they would be infinite loops which may be suboptimal. But that is optional I guess. Maybe only enable when DEVELHELP is defined or sth.

[jnohlgard]

@jfischer-phytec-iot I will test the MCG later.

I will focus on implementing lpm_arch.c next (using LLWU).

[jnohlgard]

@Farthen I wish to use the DMX32 bit for FEE mode as well. I have only an RTC 32kHz crystal to use on most of my boards and I wish to be able to reach 96 MHz core clock.

[jfischer-no]

@gebart great, that I wanted to make next, MCG may need to be extended with respect to LPM. How can I help you?

[jnohlgard]

@jfischer-phytec-iot You can comment on my idea for the lpm design:

My general idea is to always strive to reach LLS mode whenever the CPU is idle. I will implement inhibitors for each power mode which will be used to signal when a peripheral driver needs to keep the CPU at a higher power mode than LLS. The inhibitors will be simple atomic counters (counting semaphores) which will be checked before entering a power save mode. We have a similar implementation in our Contiki port, which I am the author of and I have permission to use so I might copy bits from there.

I don't think we will need to map all of the power modes in RIOT to separate modes but rather always try to go as low as the currently active drivers allow. The LPTMR0 is fully functional even in LLS, so hwtimer should always be able to wake the CPU.

[jnohlgard]

@jfischer-phytec-iot Did you test the i2c driver on your device?

I need to interface with some i2c devices but I have not had time to read up on the Kinetis I2C module yet, so I was hoping it will "just work".

[jnohlgard]

Regarding syscalls I think this may even be moved to cortex-mX_common

[jfischer-no]

@gebart

It would be very convenient if we moved/merged our common parts of the ldscript, rename and refactor my K60-base.ld and adapt the kw2x ldscript to reduce it to only defining the physical memory regions and include kinetis-base.ld for the rest.

Yes, it even fits everything so far.

git mv ...

cpu/k60/ldscripts/data.ld -> cpu/kinetis_common/ldscripts/data.ld
cpu/k60/ldscripts/debugging-sections.ld -> cpu/kinetis_common/ldscripts/debugging-sections.ld
cpu/k60/ldscripts/flash-security.ld -> cpu/kinetis_common/ldscripts/flash-security.ld
cpu/k60/ldscripts/stack.ld -> cpu/kinetis_common/ldscripts/stack.ld
cpu/k60/ldscripts/text.ld -> cpu/kinetis_common/ldscripts/text.ld
cpu/k60/ldscripts/vector-table.ld -> cpu/kinetis_common/ldscripts/vector-table.ld

..add kinetis-base_m4.ld

I am not familiar enough with the Kinetis M0 variants to know if it is adaptable for the kw0x as well.

I think that almost everything can be reused.

Can you make a PR? Do you have time for it?

[jnohlgard]

Actually, only the kinetis-base.ld is used, I used the other split ldscripts before but it turned out that it was not really helping and it was just hard to get an overview in the text editor so I copied them back into one big section file (K60-base.ld)

[jnohlgard]

@jfischer-phytec-iot I can make a PR for getting the ldscripts into kinetis_common, can you update your cpu ports to use the scripts and I'll update the K60 port?

[jfischer-no]

@gebart

I can make a PR for getting the ldscripts into kinetis_common, can you update your cpu ports to use the scripts and I'll update the K60 port?

Yes.

[jfischer-no]

@gebart I have looked at your syscalls.c. Not so bad, but depends on devio. Would it be easier to move it with devio to kinetis_common for now?

[jnohlgard]

@jfischer-phytec-iot do you have the desire/time to work on migrating the devio and syscalls part from k60+kw2x to kinetis_common?
It would be beneficial in the long run to share as much as possible between the Kinetis CPUs.

[jfischer-no]

@gebart Yes, I think this is the better solution, even if it takes more time now. Later, it will make the review for K60 and KW2X easier.

[jnohlgard]

We should add default handlers for the standard exceptions (hard fault, usage fault, memmanage etc.) to kinetis_common, similar to what is done in #2402 for the nRF cpu

[jfischer-no]

We should add default handlers for the standard exceptions (hard fault, usage fault, memmanage etc.)

WIP -> 81cb7fa

This consumes approximately +400 bytes flash. crash.c could also be slimmer and the index is not necessary, because error is uniquely identified by the string. It makes more sense to print some ARM registers instead of index.

[jnohlgard]

@jfischer-phytec-iot Regarding registers in hardfault handler, see https://github.com/gebart/RIOT/blob/2d1d87b98aee1008057dbecc83f51f72216db4c8/cpu/k60/fault-handlers.c

You'll also need an ASM trampoline something like the following (declared with __attribute__((naked))):

https://github.com/gebart/RIOT/blob/2d1d87b98aee1008057dbecc83f51f72216db4c8/cpu/k60/interrupt-vector-k60.c#L310

[jfischer-no]

@jfischer-phytec-iot Regarding registers in hardfault handler, see https://github.com/gebart/RIOT/blob/2d1d87b98aee1008057dbecc83f51f72216db4c8/cpu/k60/fault-handlers.c

@gebart Sorry, I had only now time for it.
I was unsure if it belongs to kinetis_common. My opinion is that it is one for cortex-m4_common/crach.c. So I left it and made as in #2402. I think it's good to start with.
Please review 14faa83

[jnohlgard]

@jfischer-phytec-iot 14faa83 looks good except for the missing prefix on the enum values. I will try it out on my WIP k60 branch.

[jfischer-no]

🔦 I am working on RIOT port for frdm-k64f. I will open a PR after #3023 is merged.

[haukepetersen]

nice. probably also makes sense to wait for #3100. Will try to get them both merged today.

[DipSwitch]

I just bought a Teensy 3.2, the k20 CPU implementation seems abandon. And there where issues with the license. If I base it off the K60 I guess I can still make the implementation?

[felinira]

Yeah sorry, I really didn't find the time to actually do the work. As the code base has evolved since starting the whole thing it would probably be best to start over. Can't promise I will pick it up again.

You can ship the freescale k20 headers though, freescale explicitely allowed this last year sometime.

[DipSwitch]

No problem! Than I have something to do in my free time ;)

[DipSwitch]

Thx for the response :D (and sorry for the spam...)

[miri64]

To my knowledge Kinetis integration is complete or am I mistaken?

[OlegHahm]

I think so, too.

[OlegHahm]

Ah, overlooked the check list.

[felinira]

you can probably throw out the k20 for now, not sure if/when I would actually find the time to take care of it and nobody else seems to need it anyways.

[jfischer-no]

I have removed k20 and kw01 from the list, I think it can be closed.