Since a while (at my current employer) we are searching for a 32 bit microcontroller which could be utilized for safety relevant task. A criteria for a certain reason was to avoid the ARM architecture, making the task more complicated. In the end we selected the PowerPC architecture, the MPC560xP line from NXP (formerly Freescale). This post summarizes our initial experiences with this chip and the available toolset for it, as viewed by someone with no former experience with it (and no experience available within the company either).
We considered several microcontrollers for our tasks, with the following end results:
- ARM: This would be the obvious choice, however we now had a reason to avoid this architecture (increased hardvare diversity in a 2 out of 2 system where the other microcontroller is an ARM).
- AVR32: We use this architecture with good experiences, however it doesn't exactly target safety relevant systems, so we avoided it. It neither helps that with the recent acquisition of Atmel by Microchip, the future of this architecture might be dubious.
- PIC32: Like the AVR32, it doesn't exactly target safety relevant systems. Within the company there are some bad experiences with this, personally I don't like the architecture due to what Microchip is doing with GCC by it (abusing the GPL).
- PowerPC: As far as I could discover, this is one of the top architectures used for safety relevant and space missions, so a quite obvious choice at first.
- Renesas: There are several architectures, some even including safety kits. However as we experienced, at least in Hungary, it seems practically impossible to get these chips, there is nothing ever stocked, and there are many months of lead time.
Other contenders were Motorola 68K, Infineon's TriCore, the former dismissed for it appeared that these are being phased out, the latter for the lack of information beyond those provided by Infineon.
We selected the MPC560xP line from NXP, and later discovered that these microcontrollers were a joint development project by ST Microelectronics, the largely equivalent SPC560Pxx.
One important foundation for our selection was the perceived availability of open source PowerPC activity which we hoped could help us starting with the architecture.
With all honesty, it was a shocking revelation to receive the first evaluation board (TRK-MPC5604P by PE-MICRO, an SPC5604P microcontroller sitting on it).
It came in a relatively nice package, which means it had a compact disc with the tools and a lot of documentation for it, at first seemingly quite useful for starting experimenting.
Before this, of course, I browsed the complete datasheet of the chip, determining that it was complex, but not something impossible to handle given our resources.
The rough plan was to start with discovering how the build process works for it, in-depth so to know what each piece of code does and how the tools interact. This normally means command line. This is required if you want to later justify the process, that it works as you intend it to work, that it generates what you want. That you can later switch over to a certified compiler when you are comfortable with the chip for a proper safety related development.
Then came the revelations.
For one, this evaluation board is, with all honesty, a piece of crap for the purpose of evaluation. The programming method provided with it just doesn't work (RAppID Boot Loader Utility). It occasionally does, sometimes it would deterministically start to work, uploading the program, but more often it fails with arcane error messages suggesting you to check whether your jumper configuration is right, which is obviously right after you checked it all the twentieth time. We had seen this happening on a Windows 7 and a Windows 10 machine.
For another, the supplied CodeWarrior tool turned out to be, well, CodeWarrior. I failed to notice this in my initial research. An unique compiler which was originally used for Apple Machintoses, but which Apple dropped favoring their own XCode even before they switched to Intel from PPC. You can find almost no information on this beast on the Internet. Only a few places ever mentioned it, in particular describing how they couldn't get its compiler working from command line using the (extensive) Freescale documentation.
So that turned out being a dead end for the purpose of starting ourselves.
Enters: ST Microelectronic
I was searching for compilers, whatever information I could get for this thing (meanwhile we were also trying to get something from Renesas or any of their distributors, but kept failing), ending up discovering the ST Microelectronics link, their SPC5 line.
That ended up with ordering a Discovery kit with the SPC560P50 microcontroller after discovering that their SPC5 Design Studio is based on GCC, lighting some hope.
Compared to the NXP kit, this board came rather bare. It was just the board all by itself, without even as much as a piece of paper describing how to start with it, which place I could visit, what to download, install to get it working.
So back to the site, and the first obvious choice is getting the studio. Of course like NXP, the place needs registration to download anything.
After it was installed, of course I went to see example programs while browsing the manuals. Find and start the wizard, select board, UART example, generate, build, debug...
Debug... I said, debug!
The button is there, but nothing happens clicking on it. The manuals tell nothing. It just doesn't work. What the heck is that "UDE Debugger" anyway?
It turns out that it is a third party software you have to install separately. This wasn't mentioned anywhere in the manuals. So I go there, do the installation, but then still nothing happens when I click the SPC5 Studio button. After some research, it turns out that I have to install that within the Studio as well (which is described in the FAQ on PLS' site, the creator of this debugger, so NOT on ST's site!). I proceed through the installation. Then the thing is there, I can see it installed in the Studio, but the menu entry described in the FAQ is not there.
How much I hate IDEs... I seriously can't understand how anyone can use these...
I gave up there. I started the debugger (UDE Starter Kit) itself, and loaded the project file in it which was generated by the Studio. But then... How am I supposed to upload this program?! The debugger can clearly communicate with the board all right, the code is listed in it but there isn't a button or menu entry anywhere to just say "upload". The example project's code is there, but no matter what, it is impossible to actually load it in the micro. Great.
In the end I created a new project within the debugger, and found how to load the .elf file, at last, the example program was actually running on the board!
Later this setup fired back badly. The UDE Debugger as it turned out, locks onto several files in the project, so while it is running, it is not possible to build in SPC5 Studio (you will get arcane errors, or even as much as nothing, yet your project wouldn't build proper). So you have to close the debugger whenever you want to build. Just awesome.
Towards the command line
Since SPC5 Studio compiles using GCC, the next goal was to ditch the Studio in order to get a clean environment for compiling (clean here means command line, Makefiles). Since Linux, Bash shell and overall environment is a lot more developer friendly than the Windows counterparts, I was looking out to do this all in this, for me more familiar environment.
The first try was to just attempt compiling the example project extracted from the Studio by the GCC version supplied with Debian Jessie (which has PPC support). Of course it failed. With a little research, it turned out that ST uses NXP's custom-built GCC.
So I went to NXP's site, and downloaded their GCC which was provided in source form, with a build.sh script in the root, without much documentation.
Let's see... Of course missing packages. I apt'ed those. Then tcl 8.3.5 is reported missing still. What? Does it need exactly that version? With some further research I figured out how to install that. But it was still reported missing!
In the end by digging in the build scripts I discovered that it was looking for tcl's version number in the tcl header at "/usr/include/tcl". In Debian these are in directories like "tcl8.6", that was why it couldn't find it. A soft link took care of the problem.
Then after twenty minutes building, it died with a simple "Error". Without telling anything on the reason. I dug in the build scripts, verbosity options, logging settings, but with no avail. I couldn't expand that vague message any more. I gave it up there to see whether I could get a compiler binary.
It turned out that such exists in NXP's S32 Studio, a tool which isn't listed for this particular microcontroller (SPC560xP). So I downloaded and started installing the Linux version.
This thing requires a license key to be inserted (the trial key is sent by e-mail upon requesting the download). When the installer arrives at that point, it offers whether to register online or offline. Neither of these work, it doesn't even look like attempting to do anything (online) before barfing out an error.
In the end we discovered that it needs root privileges even to just save a file for offline license request to an user-accessible directory. Ridiculous.
Anyway, it could be installed, and had the compiler I needed.
I extracted the compiler, then ditched that virtualized Linux for good which I dedicated to install this beast of software without even trying it.
The compiler sort of worked, it could compile the example, however couldn't link it. "ld" missed "-lc" and "-lm", which turned out to be the standard libraries, which of course exist in the compiler's tree. While I could build by providing the library path in the makefile manually, I figured out that it fails due to that the compiler has a hard-coded path in it.
You have to place it at "/opt/freescale/powerpc-eabivle/x86_64-linux" (so the "bin", "lib", "include" etc. directories are there), then make a symlink named "lib" in the "powerpc-eabivle" directory there pointing at "newlib/lib" there.
If you set your path correctly, and update the "TRGT" definintion within the example program extracted from the SPC5 Studio (along with fixing a dozen of backlash-forward slahs anomalies in path separators), it will (should) compile fine.
A small pitfall in the example
A first obvious thing to try was to put a different message on the UART to see whether it all works fine (UART example for the SPC560P50 based Discovery board from ST Microelectronics). After compiling and burning this into the micro, all I got was an apparently stuck program. If I just modified characters within the existing string, it all seemed to work.
Of course this all happened while I didn't discover all the pitfalls in the above mentioned miserable pieces of software failing to cooperate, so I was quite lost on what to do. For about a day I was battling with the debugger trying to find why it fails to let the program running.
The problem turned out to reside in the "components/spc560pxx_low_level_drivers_component_rla/cfg/lldconf.h" file. Here there is a SERIAL_BUFFERS_SIZE define, which, contrary to the Doxygen documentation above it, it set to 16, making the routine in main.c returning an error, which causes the program being apparently stuck if you increased the string's size.
Evil. This is just plain evil.
Anyway, getting past this, it works. It is possible to go on.
I think this adventure was, well, quite revealing.
Not to mention all the crap within the licenses I had to accept (and there were numerous, the NXP CodeWarrior threw maybe more than twenty of these tiny windows during its several hours long installation procedure). There are two items in particular which I found a little more outrageous than usual.
The following term is in the NXP-Freescale license for CodeWarrior:
17. MONITORING. You will monitor the access to and use of the Software. With prior written notice and during Customer's normal business hours, Freescale may engage an internationally recognized accounting firm to review your software monitoring system and records deemed relevant by the internationally recognized accounting firm to confirm your compliance with the terms of this Agreement or U.S. or other local export laws. Such review may include CodeWarrior (or successor product) report log files that you will capture and provide at Freescale's request. You will make records available in electronic format and shall fully cooperate with data gathering to support the license review. Freescale will bear the expense of any such review unless a material non-compliance is revealed. Freescale will treat as confidential information all information gained as a result of any request or review and will only use or disclose such information as required by law or to enforce its rights under this Agreement.
This is also in an NXP-Freescale license, for the S32 Studio:
6. PATENT COVENANT NOT TO SUE. As partial, material consideration for the rights granted to you under this Agreement, you covenant not to sue or otherwise assert your patents against Freescale, a Freescale Affiliate or subsidiary, or a Freescale licensee of the Licensed Software for infringement of your Intellectual Property Rights by the manufacture, use, sale, offer for sale, importation or other disposition or promotion of the Licensed Software and/or any redistributed portions of the Licensed Software.
I don't think either needs much comment. The item about patents is hairy considering the situation of software patents: such a term in a license is practically openly stating that they are using the law system for a sort of (legal) warfare. Like if you depend on us, then you have no rights against us. We have more money, better lawyers. End of story.
The quality of the boards and associated software were, well, let's just say they weren't reassuring at all.
Just think about that. These things are used in your cars. To operate the airbags for example (if you search for this chip, you will find various sites, mostly Russian, on how to reset a crash counter in it).
Of course it doesn't necessarily mean that the car is unsafe, that these microcontrollers aren't fit for their safety relevant tasks.
The problem is rather that how obscure they are, and how dubious effort is invested in opening them for "newcomers", those who have no prior experience with them, while these micros are used in masses by the big players of the industry.
So ladies and gentlemen: This is capitalism. Without the competitive market.
Make a comment
- Please be polite (Leave all your trolls in their respective caves).
- If #1 fails, don't feed 'em. They bite.
- No links allowed. It won't pass. Neither chains. Use '(dot)' notation.
- Spam reeks.
- Text is (some day will be) formatted with Markdown.
- Your mail address is only visible to me: I understand you also don't like #4.
- The mail address you provide is also used to fetch your Gravatar.
- Danger! High voltage! Right between your "Post Comment" button and ground.
- Still want to comment? Go ahead! :)
No comments so far. Be the first to comment!