Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
9 years, 6 months ago.
mbed RTOS support on K20D50M?
Hi folks,
It looks like there isn't support for the mbed RTOS on the K20D50M board.
Is this just because it's a recent board, and hasn't been done yet? Or is there a fundamental reason why the RTOS can't be ported to it?
I did a little bit of investigating, and after adding some defines for TARGET_K20D50M to RTX_Conf_CM.C , the compile gets stuck on an unknown opcode (VSTMDBEQ) in HAL_CM4.c . That's where things start to get beyond my debugging ability.
Is this a work in progress? Is there a fork in github that has K20D50M RTOS support, and I just haven't found it?
1 Answer
9 years, 6 months ago.
There shouldn't be a fundamental reason for it. Normally adding those few defines would do the job, but the K20D50M has had a kinda rocky start in mbed (where it took something like half a year before it was finalized :P), and if I look at it correctly the issue is that it is defined as core M4 instead of core M4F. And that might also be related to this. (No idea if it would accept a M4 without floating point unit, but I think the K20D50M has a floating point unit.
So I was mistaken I see, and still cannot edit answers. The K20D50M has no FPU, its larger brothers do have it. That instruction is only available for core M4F targets. I think some part of the code there needs to be between #ifdefs, which is specific to the FPU. But I don't know if the code in that file is made manually or from somewhere else.
posted by 27 Oct 2014Hrm, curious. It looks like that board has a MK20DX128VLH5 chip.
Sure enough, that chip doesn't have an FPU: http://cache.freescale.com/files/32bit/doc/prod_brief/K20PB.pdf (page 9)
Interesting, since I thought CM4 implied FPU. I guess not. Changing the K20D50M target to a "Cortex-M4F" does get it to compile, but of course that code wouldn't actually be valid for the K20 core.
So ... now we're stuck, I I think. It looks like in HAL_CM4.c, the offending opcodes aren't surrounded by any sort of a differentiation between FPU and non-FPU cores. As far as I know, this file comes from ARM themselves, so support simply hasn't been written yet. I don't know my ARM assembly, so I won't even try a hack around stacking up the FPU registers, since I doubt it's as easy as define guarding those save & restore lines.
This is all in service of the crackpot idea of making the Teensy 3.1 mbed capable. They use a similar chip, MK20DX256VLH7, that only varies in the peripherals, memories, and pins.
posted by 27 Oct 2014But doesn't the Teensy have an FPU possibly? Then for Teensy support you might just add it as new target in the source files.
From what I understand of it, with some googling, is that it stores the state of the FPU (or something similar), and I think just putting it in #ifdef TARGET_M4F should do it (together with some lines before/after it). I might have a look at it soonish, however since as you say I guess it is supplied by ARM I wouldn't know if changes to those files would be accepted. Might as well bother some mbed dev about it :)
posted by 27 Oct 2014