Two days in a row, yet.
Yesterday: one of the toaster controllers has an Issue. My latest firmware build, which has a minor update to the FPGA code (Xilinx Spartan 6, code in Verilog with some third-party VHDL spliced in), has developed a lack of function in an area largely unrelated to the change (it shares a clock, and some inputs and outputs, but the state and logic are entirely autonomous).
Careful examination of the Verilog code shows no freaking way it can be doing what it's doing.
After much futzing around with bringing internal signals out to test points so I can stick a scope probe on 'em, I narrow it down: there's a register which should always hold one of three constant values, all of which happen to be 20 million at the moment. There's an 'initial' block, which assigns value I, and a condition in which it's assigned value F, and an "if not that, but this other thing" which assigns value N. If neither condition (both are synchronous, by the way) is met when the clock ticks, the register retains its current value.
Well, that register seems to have been ending up with zero stored in it... meaning that the first condition should have been met (it was; that's one of the outputs) and the register should have been reloaded with value F (it wasn't).
Some kinda optimization thing, I guess. I split the "if not that, but this other thing" into "if not that, load value N, and also if that other thing do other stuff"; this solved the problem at hand.
Then there was this afternoon...
Other project involves some ARM Cortex M3 code, originally developed under an expensive proprietary IDE. I converted the project to build & debug under Eclipse, which turned out to be a lot less trivial than it sounds, but that's another story.
Today's task was to set up, on the client's software guy's Linux box (Ubuntu 14.10, Uncanny Ungulate), a duplicate of the cross-development environment. So, the Armstrap bundle of Eclipse & toolchain, plus CDT, plus the GNU ARM Eclipse plugins. And stlink, built from source, which of course brings its own annoyances, but that, too, is another story.
In preparation for this, I installed all the stuff on my laptop yesterday evening, and verified that it worked.
So I get to the client site....
Installation of Armstrap: no problem. Addition of CDT and the GNU stuff: no problem.
Try to build the project: problem. Specifically, it can't find arm-none-eabi-g++ (nor, trying a dummy project, arm-none-eabi-gcc). Says file not found. I can find the file with ls; what gives?
Mess with $PATH. Fiddle with project settings. Mess with all kinds of things. Still not found.
WTF????
Continue poking at the arm-none-eabi-gcc executable. Try to run it from the command line: file not found. Try to run ldd on it: not an executable file???!?
Eventually the answer turns up: those are the errors you get if you try to run 32-bit (ia32) executables on 64-bit (amd64) Linux without the compatibility libraries installed. Install those, and the build works. Seems I'd installed them long ago on my laptop, probably when I installed some other prebuilt distribution of the ARM GCC toolchain and it turned out to be ia32-only.
Then there was some further futzing, and then we needed to look up the name of the ia32-edition ncurses package so that gdb would run, and finally we had success (modulo a malfunction with the actual embedded application, but that was easy by comparison).
Or, and Umbongo? Not a fan. Aside from the stupid "Unity" desktop environment - let's borrow some bad ideas from Apple, and give Microsoft some new bad ideas all our own! - the package manager (software center, or whatever they call it) is remarkably unhelpful; many things we needed were out there in the apt repositories waiting to be installed, but were not findable with the search function. Gotta find the names out there on the Web, and then apt-get will do its magic.
Recent Comments