.png){kind=small}
In this post I would like to describe process of setting up NXP FRDM-K64F development environment under Linux and start Zephyr development using it.
Why NXP FRDM-K64F ? I choose this platform mostly because of ready to use guide about using 802.15.4 communication by attaching TI CC2520, which was presented here.
Typical wireless stack starts with 802.15.4, then 6LoWPAN adaptation and then IPv6, which carries application protocols. 6LoWPAN compress IPv6 so it can fit BLE and 802.15.4 and it is dedicated for embedded systems with very limited stack. Using IPv6 is very important for IoT market because scalability, security and simplified application implementation in comparison to custom stack also it can provide known protocols like UDP on transport layer.
I tried to evaluate Zephyr networking stack for further use in customer applications. But having even greatest idea for project requires development environment and ability to debug your target platform that’s why I wrote this tutorial.
NXP FRDM-K64F setup
I started with initial triage if my NXP FRDM-K64F board works:
|
|
On /dev/ttyACM0 I get:
|
|
So it works great out of the box. Unfortunately it is not possible to flash using typical Zephyr OS command:
|
|
NXP FRDM-K64F have problems with debugger firmware and that’s why OpenOCD refuse to cooperate. Recent CMSIS-DAP firmware can be installed by using this guide although it has speed and debugging limitation about which you can read here.
I followed this post to build recent version of OpenOCD from source.
Custom OpenOCD can be provided to Zephyr make system, by using OPENOCD
variable, so:
|
|
Both worked fine for me. I realized that I use 0.8.2 Zephyr SDK, so this could
be possible issue, but it happen not. Neither OpenOCD provided in 0.8.2 nor
0.9 Zephyr SDK worked for me.
Zephyr SDK upgrade
For those curious how to upgrade Zephyr SDK below commands should help.
To get location of SDK:
|
|
To upgrade:
|
|
Flashing sample Zephyr application
Because SDK provided OpenOCD didn’t worked for me I started to use one compiled by myself.
zperf is network traffic generator included in sample applications of Zephyr.
It supports K64F, so it was great place to start with networking.
|
|
On terminal I saw:
|
|
Testing scenarios are described here. Unfortunately basic test hangs, what could be great to those who want to help in Zephyr development. I tried to debug that problem.
Debugging problems
To debug zpref application I used tui mode of gdb:
|
|
Please note that before debugging you have to flash application to your target.
Unfortunately debugging didn’t worked for me out of the box. I struggle with various problems trying different configuration. My main goal was to have pure OpenOCD+GDB environment. It happen very problematic with breakpoints triggering exception handlers and GDB initially stopping in weird location (ie. idle thread).
I
asked
on mailing list question about narrowing down this issue. Moving forward with
limited debugging functionality would be harder, but not impossible -
print is your friend.
NXP employee replies on mailing list were far from being satisfying. Main suggestion was to use KDS IDE.
Digging in OpenOCD
In general there were two issues I faced:
|
|
timeout value and retval value were added for debugging purposes. First
conclusion was that increasing timeout doesn’t help and that crc failure could
be caused by problems with issuing halt, so it sound like both problems were
connected. On the other hand those error had no visible effect on flashed
application.
DAPLink
Recently DAPLink was introduced and on
mentioned previously mbed site it replaced previous CMSIS-DAP firmware, but
there is no clear information about support in OpenOCD except that pyOCD
should debug target with this firmware. Unfortunately DAPLink firmware provided
by NXP for FRDM-K64F didn’t worked for me out of the box, what I tried to
resolve by asking question here.
It looked like more people have problems with debugging. Proposed solutions are KDS, using Segger and P&M firmware instead of CMSIS-DAP.
Kinetis Design Studio
This was suggested as solution, by NXP and I get to point where I have to give it a try. It is obvious that each vendor will force its solution.
I don’t like idea of bloated Eclipse-based IDEs forced on us by big guys. It looks like all of semiconductors go that way TI, STM, NXP - this is terrible for industry. We losing flexibility, features start to be hidden in hundreds of menus and lot of Linux enthusiast have to deal memory consuming blobs. Not mention Atmel, which is even worst going Visual Studio path and making whole ecosystem terrible to work with.
Of course there is no way to validate such big ecosystem, so it have to be buggy.
I know they want to attract junior developers with “simple” and good looking interface, but number of option hidden and quality of documentation lead experts to rebel against this choice. Learning junior developers how custom, vendor Eclipse works is useless for true skill set needed. It makes people learn where options are in menu, but not how those options really work and what is necessary to enable those. We wrapping everything to make its simple, but it turns us into users that don’t really know how system works and if anything will happen different then usual we will have problems figuring out the way.
Portability of projects created in Eclipse-based IDEs is far from being useful. Tracking configuration files to give working development environment to other team members is also impossible. Finally each developer have different configuration and if something doesn’t work there is no easy way to figure out what is going on. Support is slow and configuration completely not portable.
Best choice for me would be well working command line tool and build system. All those components should be wrapped in portable containers. We were successful in building such development environment for embedded Linux using either Poky or Buildroot. Why not to go mbedCLI way ?
Luckily KDS is available in DEB package, but it couldn’t be smaller then 691MB. I have to allow this big bugged environment to hook into my system and I’m really unhappy with that.
|
|
Then this:
It was very clear information. Maybe adding path log would be also useful ? Finally problem was in lack of disk space.
KDS OpenOCD
Interestingly OpenOCD in KDS behave little bit different then upstream. There
were still problems with halt and crc errors. Unfortunately flashing is terribly
slow (0.900 KiB/s). NXP seems to use old OpenOCD
Open On-Chip Debugger 0.8.0-dev (2015-01-09-16:23) It doesn’t seem that
OpenOCD and CMSIS-DAP can provide reasonable experience for embedded systems
developer.
What works ?
After all above tests it happen that the only solution that seem to work without weird errors is Segger Jlink V2 firmware with Segger software provided in KDS.
To configure working configuration you need correct firmware which can be downloaded on OpenSDA bootloader and application website. After updating firmware you can follow with further steps.
Flashing with Segger
To flash you can use JLinkExe inside Zephyr application:
|
|
Where ~/tmp/zephyr.jlink
|
|
Debugging with Segger
Then you can use JLinkGDBServer for debugging purposes:
|
|
Output should look like that:
|
|
To debug application you can use debugger provided with Zephyr SDK that you used to compile application.
|
|
Then you have to connect to JLinkGDBServer:
|
|
For zperf same application output should look like that:
|
|
If you need to reset remote side use:
|
|
It happens that load piece was also missing part for CMSIS-DAP. This command
gives GDB access to program symbols when using remote debugging.
Summary
In terms of speed there is no comparison between Segger and CMSIS-DAP. First gave me speed of ~50MB/s second ~2MB/s. Unfortunately Segger have to be externally installed with KDS or from binaries provided by Segger. Zephyr also would require some modification to support that solution. CMSIS-DAP has a lot of weird errors, which can confuse user. There is no information if those errors affect firmware anyhow, but professional developers don’t want to wonder if their tools work correctly, because there is plenty of other tasks to worry about. CMSIS-DAP is very slow OpenOCD from KDS version is 20x slower then upstream OpenOCD, but advantage of this is that it works out of the box with Zephyr what can be good for people starting.
If you struggle with development on FRDM-K64F or have some issues with Zephyr we
would be glad help. You can easily contact us via
socialmedia or through email
contact<at>3mdeb<dot>com. Please share this post if you feel it has valuable
information.
