First experence with KDS (Beta) with FRDM-K64F

[mjbcswitzerland]

Hi All

Here are some notes made whilst working with the new KDS for the first time with a FRDM-K64F board.

Installing KDS under Windows

The installer is simple to use. Just execute the setup "KDS-v1.0.1.exe" and follow the instructions.

The setup program is around 500MBytes in size and the installation process takes about 20 minutes to complete on a medium powered laptop. The actual installation starts after clicking through only a few typical setup screens.

There are no parallel installations of drivers etc. (that are noticeable to the user) but the PC must be restarted after completion for the configuration changes to take effect.

The release notes discuss a couple of known issues with the Beta version and points to the KDS community forum: https://community.freescale.com/community/kinetis-design-studio

There are two directories created:

c:/Freescale/KDS_1.0.1

c:/Freescale/KSDK_1.0.0-Beta

Starting KDS

During the installation a program was added to the program start menu. Optionally there will be a desk top link to it as well (depending on whether this was checked during the install process). The program starts as Eclipse typically does and may take a few minutes to launch the first time, asking which workspace is to be used at some point along the way.

Importing CodeWarrior 10.x projects into KDS

It is likely that KDS users have CodeWarrior projects that they would like to be able to use with KDS instead, or even in parallel to CW.

An attempt to import an existing CW10.5 project was successful in as much as the import of the files structure and targets was correct but there were no tool settings available to use the project once in the workspace. Although there is a context sensitive menu item named "Convert from CodeWarrior File..." this didn't react to attempts to use it.

When trying to open the project later in CW10.5 it failed since some of the project setups had been modified by the attempt in KDS; this means that a backup of the original files .cproject and .project, etc. should first be made before experimenting.

It was therefore decided to configure a new project based on internal examples to verify that this would be efficient.

Compiler

KDS uses GCC 4.8.0 (CW10.5 used GCC 4.7.3). The standard settings for this compiler don't support asm() [for writing assembly in c-code] but instead required __asm__(). Otherwise all code is compatible.

The settings are very similar to CW10.5 settings (not all at the exact same locations but easily found) and so setting up a project again is not a huge task.

There are however a few things that don't work correctly (in comparison to CW10.5) which required some experimentation to work out what was (not) happening correctly and essentially resulted in some slightly nasty path names having to be introduced as workarounds. It may be that these will be improved in later versiosn so that they can be cleaned up appropriately:

1. Builder Settings.

The build directory is set to ${workspace_loc:/project_name}/Project_Flash but this is fixed and can not be modified to a (possibly) more convenient locations.

2. Path variables can be set but they don't work when used for defining locations where tools should should find files etc. For example it is possible to use a linker script path such as "${ProjDirPath}/Project_Settings/script.ld" but if ProjDirPath is replaced by a valid path variable (eg. PROJECT_LOC, which is the same location) it results in the linker just receiving "-T /Project_Settings/script.ld" [the path variable has been completely lost].

However build variables can be added which can be used form the same function so this not serious.

Building projects with KDS

KDS is missing the blend-in target drop-down which can be used to select a build target from the project explorer field but generally when editing and building one doesn't really notice any difference between working with CW10.5 or KDS.

FRDM-K64F

This board is delivered with mbed debug support but Windows users will need to install the mbed serial port driver from http://mbed.org/handbook/Windows-serial-configuration to be abel to wwork with it.

If bad code is loaded to the board it is possible that the debugger can no longer connect to the board. This is seen by the red LED near to the debug connector flashing quickly. In this case use the debugger's integrated USB-MSD loader to program a software that operates normally. Keep a known good binary file at hand for such a case. See also Eric Styger's blog entry for more details: http://mcuoneclipse.com/2014/04/19/recovering-frdm-k64f-mbed-board/

The debugger on the board is CMSIS-DAP which is selected as OpenOCD (SWD mode).

If the installed debugger gets lost, which can happen if overwritten by a different code using its bootloader capabilities, the latest version and a description of how to load it can be found at http://mbed.org/handbook/Firmware-FRDM-K64F - the version at the time of writing is called "k20dx128_k64f_if_mbed.bin"

When configuring a debug connection there are choices for the GDB OpenOCD, PEMicro and Segger J-Link. The FRDM-K64F uses the OpenOCD connection. The first trick to using this is to add

-f  kinetis.cfg

to the Debugger's "Other options" configuration" otherwise the debug configuration won't work with the connection.

There is a P&E version of the debugger which can be found in "C:\Freescale\KDS_1.0.1\pemicro\opensda". See also https://community.freescale.com/docs/DOC-100718

In the KDS_1.0.1 this is called "DEBUG-FRDM-K64F_Pemicro_v108.S19" which is in SREC format and not suitable for loading to the board using the MBED loader. After conversion to binary it is possible to load it, however the debugger no longer started and so the original "k20dx128_k64f_if_mbed.bin" was reinstalled.

Unfortunately attempts to load code to the board or debug were unsuccessful although the debugger would connect and not give any error messages. It was seen that, although there was a lot of activity at the debug interface, the software that was already loaded continued to operate undesturbed. Any attempt to do anything with the debugger when connected resulted in it saying that there was no connection.

In comparison, the MBED debugger worked well with IAR, after adding the patch files.iar.com/ftp/pub/box/freescale/K22-K24-K63-K64-patch-20140130.zip [This is detailed in the Freescale document: http://cache.freescale.com/files/soft_dev_tools/doc/user_guide/K64BTLDRQSG.pdf]

Working without debugger

Thanks to the MBED loader on the FRDM-K64F board it is still possible to load binary files to the board so that they can run.

It was however found that if Flash configuration settings in the binary image to be loaded are not all 0xff (apart from the non secured but that can be '0') the MBED loader would crash and so leave an invalid code programmed that would not operate. As long as the flash configuration values are left at 0xff it is reliable.

Conclusions

- KDS uses a different GCC compiler build which supports more core types (for K and KL Cortex-4 and Cortex-m0plus are used)

- the environment differs only slightly from CW10.x and runs fairly smoothly (faster than expected)

- there are a few workarounds needed to get an existing project configured in a comparable manner but nothing serious - annoying is mainly the fact that the location of the output directory can not be defined and so each target clutters up the embedded code directory a bit

- First attempts with flash loading and debugging failed but the code could still be loaded and verified using the built in MBED loader - the reason for this was not yet identified since there were no error messages when connecting or loading

- Due to the nature of Eclipse it is not possible to open a project in both KDS and CW10.x at the same time since they both want to have their (different) project files at the project root. The method used to move between CW10.5 and KDS (and also Atollic) is to keep a backup of the project files for each IDE and copy the project file set to the project root before opening the IDE to be used for a particular session

Essentially, once the debugger issue(s) can be solved and assuming that it then allows flash loading and basic debugging KDS should be able to replace CW10.x for all "basic use" since it doesn't look to have any major disadvantages for pure project building tasks.

Regards

Mark

[kenno]

Nice review of KDS. I've got it installed on Ubuntu 14.04 (64-bit), though the Linux KDS 1.0.1 (beta) is a 32-bit application. I am able to compile code for FRDM-KL46Z. I haven't had a chance to compile any codes for FRDM-K64F yet, but will try it soon. MountainMondays

[EdSutter]

Mark,

Thanks for the details; but I'm still struggling a bit...

I got my hands on a K64F FRDM board and have started trying to attack it from several different angles.  First I played with mbed.  It worked fine, but I got tired of that quick.  I moved over to the SDK, but found I couldn't build any of the apps (see: https://community.freescale.com/thread/324061 ),

so now I've installed KDS, and created my first project following the KDS help text titled: "Kinetis Design Studio [beta] Quick Start Guide".

So, with KDS, I created my project standalone with SDK and PE enabled, so I had to define CPU_MK64FN1M0VMD12 to get around the fsl_sim_features.h issue. Then I just clicked on "Clean Project" and "Build Project" and magically it built without error.  This is where the confusion starts...  What did I build? :-)  (and how do I add to it?) 

Seriously, I'm assuming its just the underlying start-up code so something like "hello world" will just work, so I "blindly" added printf ("hello world\r\n"); to main.c, built it and then dropped the .bin file into the mbed window (see note below), but nothing happened (would have been shocked if something did).  I assume the PE and SDK provide some API that I can hook to from main() if I want to, but haven't read enough yet to be sure.

So, all kinds of questions could be asked at this point; however I guess the first question is: am I starting off on the right path?  If yes, how do I use PE to pull in peripherals (like console UART, ethernet, SPI, etc...)?  That must be documented somewhere, but I didn't find it (note: I'm not familiar with CodeWarrior, so if this is something CW-ish, I'll need to do more reading.

Thanks for any pointers you may wanna throw my way,

Ed

NOTE...

At the moment my Segger JLink does not have the adapter cable to plug onto the FRDM board (one is on order), so I'm limited to building a binary with KDS and dropping it into the mbed window.  I followed the instructions here:

http://mcuoneclipse.com/2014/04/20/binary-files-for-the-mbed-bootloader-with-eclipse-and-gnu-arm-ecl...

[mjbcswitzerland]

Ed

If you load the debugger from here Using FRDM-K64F with P&E and Segger OpenSDAv2 Firmware you shouldn't have any problems loading and debugging using KDS (the mbed one doesn't work for debugging).

I can't help with PE since I work with the uTasker proejct which has all drivers/protocols pre-configured in the code and so doesn't need any pre-processing steps.

If you are interested in playing around with different solutions also take a look at CooCox - it is yet another Eclipse based IDE but supports some Freescale devices (Freescale Freedom boards and including full peripheral register views) and has its own sort of PE built into it too (called a repository, so you can set check boxes as to which RTOS, peripherals etc. that you want in your project). Although it doesn't inherently include the K64F it is otherwise quite advanced and somewhat easier to use than KDS - it even works with a project manager as found in traditional IDEs (solving one of Eclipse's main "pains" for embedded systems). It took me one hour from install until a complete project was setup, built, loaded, (debugger verified) and working - whereas KDS took a full day to complete the same task. The KDS developers would be advised to also take a look because it is pretty slick!

Regards

Mark

[EdSutter]

Mark,

Great, I'll look into that firmware, but at the moment I'm not concerned with debugging.  I'm still just trying to understand what PE and the SDK give me, and whether or not they are the right route to take with this.  I've played with CooCox a year ago when working with SimpleCortex.  My initial goal for this is to port my bootloader (http://www.umonfw.com) to the FRDM-K64F.  I haven't done much work with these M3/M4 devices except for a few other ports of uMonM.  I'd like to get more experience with them just to see if uMon-M is a practical approach for development on some of these bigger (more flash/ram) MCUs.

Anyway, I'm gonna give KDS a bit more time, but I just may shift over to CooCox if the fog doesn't clear shortly.

Thanks again,

Ed

[mjbcswitzerland]

Ed

I am not exactly sure about what you are trying to get out of a particular IDE but I think I can sum up my own interpretation of the various offerings based on the fact that I have 'ported' and maintain all KL and K parts on the following platforms:

• Freescale's Kinetis Design Studio (KDS)
• Freescale's CodeWarrior 10.x
• Rowley Associate's Crossworks
• CooCox CoIDE
• IAR Embedded Workbench
• Keil µVision
• Atollic Studio for ARM
• Standalone GCC from Makefile
• VisualStudio for Kinetis simulation

1. Basically the IDE is doing three main, basic tasks (there are of course other [options] such as version management, special test strategy testing and some wizards to create new projects or code bases, etc.):
- editing the code [personally I rarely do this in the IDE since VisualStudio is my favourite editor]
- building the project [in many cases this can be done faster and easier by simply calling the make file that is created]

- loading and debugging [since it is also possible (and usually much more efficient) to debug in a simulation environment and load using a boot loader this is also not often needed]

As seen, the IDE is almost redundant a lot of the time.

2. Most IDEs use GCC (with exception of IAR and Keil and other 'high-end' possibilities that usually produce a little tighter code) and moving projects between different environments is usually a case of setting up the IDE correctly so that it effectively creates the same make file as the others (in GCC cases). The higher-end IDEs tend to be a bit simpler to use but still may have some of their own quirks (pragmas, asm(), linker scripts etc.) but it is pretty easy to get a project building with all. New Eclipse IDEs may be a bit overcomplicated and try to dictate the user's methods a bit and can also cause some headaches to get the simple setup working again but at the end of the day they can be twisted to get the essentially basic job done - once set up the work is effectively completed [until the next version which may bring in new incompatibilities...]

3. The most interesting aspect of the IDEs is therefore their ability to debug on HW when needed - some are better than others and I often find myself building in one environment and using the debugger from another when there is some low level code that needs to be understood. Having a bit of flexibility with alternative choices is useful if one debugger decides to stike a bit or happens to have some weakness in a certain situation]. Therefore I prefer not to restrict myself to one tool chain because it may reduce flexibility and result in unnecessary problems in certain situations.

4. Personally I don't use code generating tools because of a few reasons:

- you get out what someone put in - it can be very good but it could be bad and I find it safer to know what is being used rather than have to solve potential problems when it turns out to be not what was really expected.

- Reliance and dependancy on case tools can be a weakness and again I prefer to have a full understanding of all lines of code that are used (with good souce code and other documentation where relevant)

- Reliance on case tools also promotes reliance on certain IDEs which goes against the goal of remaining independent and flexible (and in the long run efficient)

- I prefer to have cross-tool and cross device dependency which the present tools don't seem to do well and so result in complicated maintenance tasks

- Although case tools do a lot, people reliant on them may get quickly stuck if they need something that hasn't yet been (fully) implemented (misisng part or missing driver etc.)

- My own work is based on many years of code base that is operational on many different processor types and maintained carefully to allow portability (the code will operate on most Coldfire and Kinetis parts without the need to maintain versions for each part used - a carefully implemented HAL and support for most peripheral drivers in a generic form (tested and proven over time and in many different industrial projects)  means that they are immediatly available without having to be generated and also they have been simulated, and validated. Case tools may generate a driver when needed but it may have been put in just a few days before by an author who hasn't experience of the fault cases that may be encountered in industrial environments so it could be just the start of an optimisation process before it is really workable. If each generated code had details of who created it (experience, name, telephone number for emergencies it may be a different situation but when I develop products and have to meet dealines in the process I prefer to know exactly what is under the bonnet!)

So which IDE should be used?
Basically the best "unrestricted" one is KDS for the K64F at the time of writing (CooCox doesn't support it fully today).

For KL parts CooCox is probably best today since it is more advanced (has register views etc.) and it is also 'really' simple to move existing projects in to it if one would like to quickly try it out (or quickly needs a solution)

For older K parts CW10.6 Special edition is best if your code is not too big, because KDS and CooCox are not general enough yet and may be won't be (?).

If you are buying a commercial grade IDE it is of course easier since they all immediately support all parts very well and so can be used immediately without any restrictions, but if you are relying on specific case tools as well then it may get complicated again...

Regards

Mark

[EdSutter]

Wow nice writeup!

Just so you know, I can count the number of times I've used an IDE for embedded work on one hand.  I used CooCox simpley because it was my hook into downloading and building my first M3/4 based project (simplecortex).  My preferred toolset is still vi/ctags/cscope/brain and whatever tool I need to transfer the application to the target. I would much prefer to avoid the vast majority of these IDEs in favor (as you said) of just knowing how the beast works myself.  That being said, I won't hesitate to grab some pre-built code (code generator, library source code, whatever...) and reuse it; hence, my interest in PE and the SDK.

Anyway, I have very limited time daily to work on this, so it'll be slow but steady...

I'll post my results when I get some.

Regards,

Ed

[randylee]

Porting existing projects:  Having lots of fun with that.

Gave up on attempting direct port as the "convert" tool doesn't launch at all.  I just created a basic shell project for the target processor (with PE enabled) and then saved the PE portion in CW10.5 and imported it in KDS.  Then added all the source files into it.

The adding the source files thing is interesting as the code is now structured slightly differently: in CW main is buried in a file called ProcessorExpert.c along with setup information and etc.   In KDS this resides in main.c -- in my case, the former file is so messy that I used it as a start and then called out to another main.c to keep the code more readable which this new arrangement broke, but that's a minor problem.

At present fighting the more interesting porting problems:

1) I've got a UART in there turned on and it's missing a define (SIM_PDD_PLL_FLL_CLOCK) that I haven't tracked down.  PE generated library code won't compile.

2) There is a worrying warning that asm() is being treated as an implicit declaration.  IDE shows it as a keyword but it's still bitching about it.

[BlackNight]

Hi Randy,

1) I think it is this issue: https://community.freescale.com/message/401739#401739

2) by default, the projects are using C99:

You can consider to change it to 'Toolchain default (GNU ISO 90), but as Mark says, that's probably not what you want.

Instead, it is probably best if you simply change asm(...) to __asm() (with two underscores).

Erich

[vittoriocastell]

Hi Erich,

in KDS, for one of your projects (USB MSD Host), every time the components code is generated I need to replace "asm(" with "__asm(" in a couple of include files (changing the compiler settings to ISO C90 resolves this error but rises other warnings).

Is there a way to change the sources from which the code is generated in order to have  __asm() instead of asm() without the need to do the file search/replace?

Thank you in advance,

Vittorio

[BlackNight]

Hi Vittorio,

are you using the Freescale provided USB components?

You can change the driver files on your machine as this component would install the driver files on your machine.

See CDE Hacking: Where is my stuff? A dissection… | MCU on Eclipse how to locate the files.

You probably want to modify the *.drv files (or search in the folders mentioned above).

I hope this helps,

Erich

[vittorio-castel]

That's it, a great help, Erich.

Changing the source files in the C:\ProgramData\Processor Expert\PEXDRV_PE5_3\Drivers\ I get now the correct syntax every time the project components are re-generated.

This saves time while debugging the projects ported to KDS.

Thanks a lot,

Vittorio

[randylee]

Forgot that was documented at the top.  The easiest thing for me to do is to change the call.... Not a problem.

the UART thing is a little interesting.  Yes, this particular project was started on a KL25 FREDM board and then ported to a KL15 in preparation for the Real Thing.  I'll drop down that path and see what I see with it.

thanx

rjl

[mjbcswitzerland]

Randy

The asm() point is detailed above. Either change the compiler setting or (preferably) modify to __asm__()

regards

Mark

[BlackNight]

Hi Mark,

thanks for your detaile review!

>>There are no parallel installations of drivers etc. (that are noticeable to the user) but the PC must be restarted after completion for the configuration changes to take effect.

The reboot is necessary because the setup installs the environment veriables to point to the Kinetis SDK installed. We have seen cases on multiple machines where these environment variables were not active/visible until a reboot. That's why the installer asks for rebooting. It would not be necessary if you are not going to use the Kinetis SDK in the New Project Wizard or elsewhere in KDS.

>>Importing CodeWarrior 10.x projects into KDS

That importer is really more a 'converting assistant'. CW and KDS are different Eclipse versions, with different settings, altough similar. But there is no simple mapping of the settings and options. I belive the best is to create a new project and then move the files over.

>>KDS is missing the blend-in target drop-down which can be used to select a build target from the project explorer field

Yes, this is a CodeWarrior Eclipse custom extension. With the move to plain vanilla Eclipse Kepler, this is lost, but as you I do not consider this as a critical item.

>>There is a P&E version of the debugger which can be found in "C:\Freescale\KDS_1.0.1\pemicro\opensda". See also https://community.freescale.com/docs/DOC-100718

>>In the KDS_1.0.1 this is called "DEBUG-FRDM-K64F_Pemicro_v108.S19" which is in SREC format and not suitable for loading to the board using the MBED loader. After conversion to binary it is possible to load it, >>however the >>debugger no longer started and so the original "k20dx128_k64f_if_mbed.bin" was reinstalled.

That .bin file is *different* from the .s19 file (memory map is different, so you *cannot* convert it and expect it to work. So you really need that *.bin file from the SDK. See Using FRDM-K64F with P&E and Segger OpenSDAv2 Firmware for instructions and the P&E firmware file.

>>It was however found that if Flash configuration settings in the binary image to be loaded are not all 0xff (apart from the non secured but that can be '0') the MBED loader would crash and so leave an invalid code programmed that would not >>operate. As long as the flash configuration values are left at 0xff it is reliable.

Yes, it seems to me that this mbed bootloader needs to mature more over time. I have passed your note the ones working on that bootloader, so hopefully this gets fixed soon in the mbed bootloader. The other issues you see with the combination of OpenOCD and CMSIS-DAP are probably because the Kinetis support in OpenOCD is rather new and needs to mature too. Fortunately it is possible to use P&E and Segger as an alternative solution.

>>- First attempts with flash loading and debugging failed but the code could still be loaded and verified using the built in MBED loader - the reason for this was not yet identified since there were no error messages when connecting or loading

I asssume this is because you loaded the converted .s19 to bin file. With this you destroyed the loaded firmware. I suggest that you load again a valid firmware (P&E, Segger or CMSIS-DAP). The other thing is: if the K20 runs wild because of this, power the board throught he other connector and flash the K64F with a Segger J-Link or P&E Multilink (Recovering FRDM-K64F mbed Board | MCU on Eclipse).

Thanks!

Erich

[mjbcswitzerland]

Hi Erich

With the debugger that you gave in the link the P&E driver works and debugging from KDS is possible.

I think the basic problem was that the KDS package doesn't look to be supplied with a driver but does have a "different" one with the "same name" as the one referenced in Kinetis SDK and FRDM-K64F Therefore it was logical to think that this must be the correct one but in a different format. I now have a copy of the correct one so can change between MBED and CMSIS-DAP when needed.

I also heard from the MBED team and they confirmed that the 'crash' is intentional when the Flash config values are not as MBED expects. However they have in fact changed this recently so that other values are accepted as long as the secure bit and the block mass erase bits are not '0'. This version is not yet available but should be released soon. Therefore this is a temporary issue - for the moment I am building with all Flash config settings at '1' (apart from the unsecure bit) conditionally on the FRDM-K64F board and will remove the condition once the new MBED driver is ready.

Therefore I could do a little work with the debugger and have the following observations:

1. At the moment I am only seeing General Registers and no peripheral registers. Is there a device setting that needs to be made somewhere to see peripheral registers? I think that CW10.x was probably using the connection setting to define this since there was no other configuration that was needed.

2. The general registers are all displayed as signed integers (although selecting one does blend in the display in hex, octal, binary). Is there a way to change the default display to the more usual HEX, which I think that most programmers would expect?
The biggest problem that the integer display poses is when the user wants to manipulate the content, whereby it is then necessary to use a calculator to convert between the hex value that is required in 95% of the cases to the integer value for the input.
Strangely this integer display is common for Eclipse (CW10.x did it 'properly') and was also an issue in ATMEL's AVR Studio where there was no way to select anything apart from integer. In that case the 'workaround' was to define a new set of registers (eg. in the watch window) which then assigned the real registers to the dummy registers but with the capability of forcing the default view that was to be used.(I did try this but it also only allowed integer display??)

Otherwise the operation is pretty much identical to the operation in CW10.x (for the standard debugging tasks).

Regards

Mark