The ARM mbed USB MSD bootloader which is used on many silicon vendor boards has a big problem: it is vulnerable to operating systems like Windows 10 which can brick your board (see “Bricking and Recovering OpenSDA Boards in Windows 8 and 10“). To recover the board, typically a JTAG/SWD programmer has to be used. I have described in articles (see links section) how to recover from that situation, including using an inofficial new bootloader which (mostly) solves the problem. The good news is that ARM (mbed) has released an official and fixed bootloader. The bad news is that this bootloader does not work on every board because of a timing issue: the bootloader mostly enters bootloader mode instated executing the application.
It seems to me that not many developers use hardware trace? ARM indicates that maybe only <5% of developers are using trace. Too bad! Why are all the ARM Cortex microcontroller vendors putting a powerful hardware (and complicated!) trace engine into their devices, if only few developers are using it? Seems like a waste of silicon and an unnecessary price adder? Well, hardware trace can be a life saver: Because only with hardware trace the most complicated bugs and problems can be solved. And maybe because only the best are using it ;-).
From time to time I face some problems which are really hard to find. Mostly these kind of bugs are very timing sensitive and depend on interrupt execution order. Maybe a dangling pointer is overwriting memory, code is running wild, or some functions are not reentrant as they should be. For these kind of bugs, good tools are worth their weight in gold. The Percepio FreeRTOS+Trace and the Segger SystemView have helped me many times to narrow down such kind problems in my applications. Another ultimate tools is hardware trace: Now I have a Segger J-Trace Pro for ARM Cortex-M in my arsenal of bug extinguishing weapons on my desk:
Dear bugs, look what I have on my desk. Your hiding time is over! 🙂
Getting a board from a distributor like Farnell/Element14/Mouser (add your own distributor) means that chances are high that the default firmware on it is written years from now because the inventory has not been updated, or because boards are still produced with that original firmware (because of testing?). So what happens if I use board with a firmware developed pre-Windows 8/10 area?
It might work, but chances are high that the bootloader and firmware is not ready for the ‘modern age’, and as a result the board might be bricked. If you still have a Windows 7 machine around (I do!), you are lucky. If not, then you need to read this article….
There are plenty of different software packages available for microcontroller these days from all the silicon vendors. Finding a good software package is one challenge, getting what I really need is another one. Freescale is now part of NXP since December 2015, so this is probably the first release of the former Freescale part now as NXP: The NXP Kinetis SDK Version 2.0.
It comes with an interesting distribution way: instead of downloading huge packages with all-and-everything in it, I can build it ‘on demand’ online and get what I need, on demand from a web-based front end:
Many tool chains and linker are able to produce S19 files, such as with the GNU tools it is the ‘objcopy‘ which does this job (see “Binary (and S19) Files for the mbed Bootloader with Eclipse and GNU ARM Eclipse Plugins“). But these tools usually cannot handle the special cases. For example on the Freescale Kinetis K64F my serial bootloader (see “Serial Bootloader for the Freedom Board with Processor Expert“) had a problem with these lines in the S19 file:
I had great plans for this Saturday: to work on really cool project. But as so many times, things turned out to be different. Maybe you have read my recent posts about printf()? A colleague wanted to use that article to the same thing with the Kinetis Design Studio on the FRDM-K64F board. I used the FRDM-KL25Z board, so I expected this to work out of the box for him too. Well, turned out that I was wrong about this, and my Saturday was used for debugging and googling about a printf() problem 😦
While things work as expected for the FRDM-KL25Z (ARM Cortex-M0+) and using the standard GNU GCC ARM Embedded from the launchpad, the application traps on the K64F (ARM Cortex-M4F) in
initialise_monitor_handles() with KDS:
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.
The mbed for FRDM-K64F firmware (http://mbed.org/handbook/Firmware-FRDM-K64F) has great potential. Unfortunately it seems that edges are still very rough: It happens very often that my FRDM-K64F board gets locked up :-(. I can see that the target CPU is constantly resetting: the red reset LED is always on:
Naturally, I have several project ideas lingering around. No time to make them all (for now). One of it is interfacing the Raspberry Pi camera with a microcontroller. To store the images, I need plenty of RAM on the device, and so far the Kinetis microcontroller did not have that. Finally, Freescale announced the K64F120 a few months back, and my ordered TWR-K64F120M board arrived on my desk, waiting to be used: Finally I get an ARM Cortex-M4F with 1 MByte of FLASH and 256 KByte of RAM :-).