In “Tutorial: MCUXpresso SDK with Linux, Part 1: Installation and Build with Maked” I used cmake and make to build the SDK application. In this part I’m going to use the command line gdb to debug the application on the board.
Many of the NXP OpenSDA boot loaders are vulnerable to Windows 8.x or Windows 10: write accesses of Windows can confuse the factory bootloader and make the debug firmware and bootloader useless. In this post I show how to recover the bootloader using MCUXpresso IDE and the P&E Universal Multilink.
I’m pleased to announce that a new release of the McuOnEclipse components is available in SourceForge, with the following major changes and updates:
- Complete refactoring for 1-Wire stack and DS18B20 temperature sensor components
- Added HID Joystick device class to the FSL_USB_Stack
- New SDK_Timer component to work with Kinetis SDK
- New ST756P LCD driver component
- New TSL2561 digitial temperature sensor driver
- Added ReadByte() and WriteByte() GenericI2C functions
- Added 64bit mapping functions to Utility
- added configUSE_NEWLIB_REENTRANT and newlib reentrancy support to FreeRTOS
- Pull resistor support for SDK_BitIO
- Many smaller bug fixes and enhancements
There are many mergers going on in the industry, and one of the largest one was in 2016 the integration of Freescale Semiconductor with NXP Semiconductors, with both providing Eclipse based IDE’s to their customer base. Consequently, the company merger triggered a merger of the IDE’s, and last week NXP has released the result: the MCUXpresso IDE.
To me, software and tools are by far more important than the microcontroller. Because the silicon is a ‘one time kind of thing’, where the software has to be maintained and working over a longer time. And at least my software usually needs to be ported to a new device, so portability and available software and tools are critical to me.
The combination of MCUXpresso SDK (formerly Kinetis SDK) and Processor Expert is unfortunately not supported by NXP. But I have found a way to get them work together in a nice way, and this article is about making that combination possible :-).
I’m using the NXP FRDM-K64F board in several projects: it is reasonably prices, has USB, Ethernet, micro SD card socket and connectors for Bluetooth classic and Nordic Semiconductor nRF24L01+ 2.4 GHz transceiver:
But one issue I have faced several times is that the board works fine while debugging and connected and powered by a host machine, but does not startup sometimes if powered by a battery or started without a debugger attached. I have found that the EzPort on the microcontroller is causing startup issues.
About a year ago, on December 7th 2015, Freescale and NXP have announced the completion of their merger. Now it is Qualcomm which wants to acquire NXP? It looks like these mergers are happening faster and faster. The reality is that merging products take more time than anticipated, and nearly one year later I can see the outcome of what comes out of the marriage between Freescale and NXP or between Kinetis and LPC: NXP has announced the MCUXpresso software and tools for Kinetis and LPC microcontroller:
This tutorial goes through the steps how to create a blinking LED application, using Kinetis SDK and Processor Expert, using the TWR-KL43Z48M board from Freescale (now NXP):
I kind of hoped that after “Why I don’t like printf()” and all my other articles about printf and semihosting, that topic would be 200% handled and I won’t have to deal with any more. Well, I was wrong and underestimated how the Kinetis SDK is interfering with semihosting. And I underestimated how many of my readers are still using semihosting (even as there are other and better alternatives), so I keep getting questions and requests for help. That’s ok, and I hope I can help :-).
So here is yet again another post about how to turn on semihosting with Eclipse, GNU ARM Embedded and the Kinetis SDK v2.0. This time with the FRDM-K64F board:
The challenge with the selection of a microcontroller for a project is: which one has the required number of UART, I2C, SPI? Combine this with the desired package (48pins, 64pins? LQFN?), the needed FLASH and RAM size and then even the hundreds of available microcontroller shrink to a handful only. And many times I need to make compromises: such as I need two hardware I2C, but the microcontroller matching all my other needs has only one I2C hardware. So I might end up with bit-banging the slower I2C bus. Doable, but not ideal.
What is cool that some of the newer NXP Kinetis microcontroller come with an interesting hardware: FlexIO. A peripheral hardware which allows me to implement a custom protocol, including driving WS2812B (Adafruit NeoPixel) LEDs with a FRDM-KL43Z board:
With Processor Expert projects it is very easy to change the heap and stack size: There is a setting for this in the Cpu component settings, under the ‘Build options’ tab:
As there is no Processor Expert in the NXP Kinetis SDK V2.0 (see “First NXP Kinetis SDK Release: SDK V2.0 with Online On-Demand Package Builder“), how to do the same in a SDK V2.0 project?
One of the most important aspects for developing complex realtime applications is get insights into what is going on the target. Segger just has released a free tool which gives an incredible useful insight view and visualization:
Starting from the baby steps for our project seems like a good idea but not very helpful though. Learning and understanding Kinetis SDK seems like a lot of work. Meanwhile, I would like to share an important piece of information that I found on my path of working on this project. Many of you might already know, but being a first time user of Kinetis SDK 1.2.0, I found that there are few differences between Kinetis SDK 1.1.0 and Kinetis SDK 1.2.0. I was trying my hands on to use the KDS with KSDK.
So, In order to create a KDS project with Kinetis SDK, I need to create new folders, add different files and the libraries to my project. I didn’t look into all this with much detail before. I would recommend all to go through this link in order to understand using KDS with Kinetis SDK1.1.0 and Kinetis SDK 1.2.0: https://community.freescale.com/docs/DOC-103288
This is how it looks after you have added everything:
Hi again to all the amazing readers of this blog! Well guess what, I am still stuck with the programming code of my NeoMatrix Demo. I think it all started with a bad choice of importing the program and libraries from the mbed to KDS. 😦
You can refer to https://mbed.org/ for other programs if you guys want to try.
Well in my last blog I told you about importing the projects and then building them. Well that was what I was trying to do but it turns out that it is not a good idea. I still have a compilation error which is there probably because of a missing assembly. Debugging the code can sometimes be really frustrating for me. 😐 So, I have decided to start from the scratch and write the code in Kinetis Design studio with the help of the Kinetis SDK. There is already the gpio example for FRDM-K64F available under the driver examples folder in KSDK_1.2.0
Getting the hands on an embedded project has always been exciting for me. So, here I am again with my blog trying to provide you with an easy to use guide for the Kinetis Design Studio 3.0.0 (KDS_3.0.0). Well, as you all know I am an intern at Freescale working for the first time on KDS, I will tell you what all we can do to start working on it with a perspective of a novice. But personally I feel KDS is one of the most encouraging IDE you can work on. So how do I start with my code for our NeoMatrix board? I am currently working with one of the demo codes for the NeoMatrix:
So, my first task is to write the code in KDS for the NeoMatrix_Demo. How do I do that? After opening the KDS 3.0.0, I need to go to File and select New and then Kinetis Project. You can see that the New Kinetis Project wizard appears once you click the File>New> Kinetis Project. Type a name and click next.
We all know that for an application to develop, for a project to work we need hardware along with the software. So here we are with our FRDM-K64F development boards, but the question is-how to make them work? I wrote in my second blog about the new getting started process by Freescale for the FRDM-K64F: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=FRDM-K64F&tab=In-Depth_Tab
This link gives me the opportunity to download the very helpful Kinetis Software Development Kit (SDK) along with the Integrated Development Environment which includes the toolchain Kinetis Design Studio. Let us talk a bit about the Kinetis SDK in this blog. So what does Kinetis SDK is responsible for? In simple terms, it is just software framework which helps us in developing applications across all Kinetis Microcontrollers. It is a package of pre-written code that developers can re-use in order to minimize the amount of unique code that they need to develop themselves.
I believe waiting makes you feel more impatient. So here I am, waiting for my NeoMatrix 8×8 – 64 RGB LED Pixel Matrix to arrive, so that we can begin working on our cool project. But looking on the brighter side, I got some time to make the beforehand preparations for our Signboard project. I took the opportunity to invest this time in finding out how to start running the Adafruit NeoMatrix with Kinetis FRDM-K64F development board. We should definitely get ourselves ready with something so that we can test NeoMatrix with FRDM-K64F as it arrives. So I thought of setting up a repository where we can turn back anytime we feel we are stuck.
This is the start of a multi-post tutorial about the Freescale Kinetis SDK, released back in April as beta version. The SDK a set of peripheral drivers, and will become the standard software foundation and drivers provided by Freescale for their ARM Cortex based devices. Similar what other vendors already do. While this is a good step, it is the same time very disruptive for my university projects with new Freescale Cortex-M devices. And with everything new (and beta), it needs time to learn. So this post is about creating a Do-It-Yourself Kinetis SDK project from scratch for Eclipse. This part is about the startup code: about everything to get the application started.