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.
One of the most important aspects of the ‘IoT’ world is having a secure communication. Running MQTT on lwip (see “MQTT with lwip and NXP FRDM-K64F Board“) is no exception. Despite of the popularity of MQTT and lwip, I have not been able to find an example using a secure TLS connection over raw/native lwip TCP :-(. Could it be that such an example exists, and I have not found it? Or that someone implemented it, but has not published it? Only what I have found on the internet are many others asking for the same kind of thing “running MQTT on lwip with TLS”, but there was no answer? So I have to answer my question, which seems to be a good thing anyway: I can learn new things the hard way :-).
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….
These days machines do not have physical serial (COM) ports any more. I do not understand why the USB group had missed to define a clean serial communication standard :-(. And the same mistake gets repeated for BLE again 😦 :-(. So every vendor and provider has its own USB CDC driver and interface. And it is really a big pain of the virtual COM/USB CDC ports installed. I have seen countless cases where “the USB UART or CDC port does not work”. So if you have such a problem, I might have a tip for you: Show hidden devices in the Windows Device manager. But in a special way I had not thought about it!
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
Typically I can create with my build the file I usually need (like an S19). See “S-Record Generation with gcc for ARM/Kinetis” how to do this in CodeWarrior, or “Binary Files for the mbed Bootloader with Eclipse and GNU ARM Eclipse Plugins” how this works in Kinetis Design Studio. The basis of all this is the GNU objcopy utility (see “S-Record Manipulation with GNU objcopy and Burner Utility”). So what if I just have an S19 (S-Record) file and need it in a different format, e.g. as .bin (binary) file for the mbed bootloader which only accepts .bin (raw binary) files?
The existing OpenSDAv1 (see “OpenSDA on the Freedom KL25Z Board“) bootloader is using the industry standard Motorola S-Record (S19) Files. However, new FRDM-K64F board (see “FTF: FRDM-K64F, Kinetis Design Studio and Kinetis SDK“) has OpenSDAv2 on it, which is an mbed bootloader. So how to create files with an IDE other than mbed for that bootloader which is present on the FRDM-K64F board by default? Well, creating binary files is one thing, but to have it working with the mbed bootloader is another challenge :-(.
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:
I knew about mbed already for some time: watching students using it for an NXP enabled board. Pretty cool stuff: mbed is an online IDE and compiler with tons of software libraries for the supported platform. So I was dreaming to have something like this for my own boards like the Freedom board. But because mbed only supported two dedicated NXP boards, that was a road block.
But then mbed announced recently that the mbed SDK is open source. Wow, that is interesting! And finally the announcement last week: mbed supports the KL25Z Freedom Board. Now they have my attention :-).