It is very valuable to have a date and time information in the binary. That way for example using a shell I can check the version of the firmware running on a device, or it can be printed on a console or UART as needed.
If you are not aware (yet?): it looks like the COVID pandemic caused a global silicon and microcontroller shortage with lead times >50 weeks in some cases. The microcontroller I have used for the MetaClockClock build (see “New MetaClockClock V3 finished with 60 Clocks” and “MetaClockClock V4 for the Year 2021“) is affected by this too, but I had luck and still enough microcontrollers to build a few more boards.
So I still have enough for building a new variant with it (not finished yet). While everyone else is waiting for the devices to arrive, here are more details and instructions for your own build.
One of the most frustrating part developing embedded applications is if the debug connection fails somehow: with all the different factors like operating system, virtual machines, USB ports and hubs, debug probe and firmware a ‘connection failed’ is my nightmare. And this is probably the most frustrating parts for my students (and myself!)
I do have a growing list of tips & tricks in “Debugging Failure: Check List and Hints“, so check this list. What I just have added is an entry for
java.net.SocketException: Connection reset
It occurred for a few students when they wanted to use the on-board CMSIS-DAP LinkServer debug connection on the NXP LPC845-BRK.
“A young man is smoking one cigarette after each other without a pause. An elderly woman observes that and says: “Young man, you are smoking like crazy! Don’t you know that there is a warning on each cigarette package that this can kill you?” The young man finishes his cigarette, looks at the elderly person and says: “Yes, I know. But look, I’m a programmer, and it is only a warning.”
I don’t smoke, and I do pay attention to warnings :-). I always try to keep my source code free of compiler warnings. And I always pay special attention to the following on:
If you are developing Linux or desktop applications with GNU tools, you very likely are familiar with gcov: the GNU coverage tool. It collects data what parts of the code gets executed and represents that in different formats, great to check what is really used in the application code or what has been covered during multiple test runs.
GNU coverage is possible for resource constraint embedded systems too: it still needs some extra RAM and code space, but very well spent for gathering metrics and improves the firmware quality. As I wrote in “MCUXpresso IDE V11.3.0 for 2021” things are now easier to use, so here is a short tutorial how to use it.
It is always good to have a close look what ends up in a microcontroller FLASH memory. For example using EHEP Eclipse plugin to inspect the binary file:
Obviously it has path and source file information in it. Why is that? And is this really needed?
- Privacy: the path or file name might expose information (secret project name?) or might be used for reverse engineering?
- Size: The strings add up to the final data/FLASH size, so this increases the need for ROM space?
So let’s have a look what is the reason for this and how it could be avoided or at least reduced.
I’m in the middle of the university exam season: means writing exams and do grading. The same time the new semester is approaching too and I need to prepare the new course material. For the classes using NXP parts I’m using the Eclipse based MCUXpresso IDE, and I just received the announcement that a new version V11.3.0 is available: time to check out what is new.
Eclipse includes a background parser called ‘Indexer’ which is used to assist the developer with various kind of information, for example jumping to a variable declaration or definition. Basically it is a parser running in the background collecting information about the sources and building up that ‘index’ data base.
The Eclipse CODAN (Code Analysis) plugin is part of CDT and is a powerful static analysis tool finding all kind of possible bugs and issues. Still to my surprise not many C/C++ developers take advantage of it maybe because they are not aware that it exists?
In this article I show a few tips how to effectively use it, especially with the NXP MCUXpresso SDK.
The holiday break at the end of the year is always a good time to finish projects started during the year. This one is about my ‘MetaClockClock’ Version 3.