Anelok: update

Werner Almesberger werner at almesberger.net
Tue Sep 30 04:45:51 UTC 2014


This has been a very quiet month, so here's a quick update on what's
happening with Anelok: I started to assemble a second board. My plan
is to keep #1 as "known to be good" reference and use #2 for "real
life" use and for experimenting with the case.

This is what it looks like in the box:
http://downloads.qi-hardware.com/people/werner/anelok/tmp/brd2-case.jpg

Most of the components I soldered are under the OLED so all one can
see are the LED and a few passive components.


Unfortunately, I then hit a snag: the MCU doesn't want to be
programmed. It says it has been set to be "secure", which is
apparently something Freescale sometimes do at their fab. Secure
means that one can't debug the core, that one can't read the Flash,
and so on.

However, unless "mass erase" is also disabled, one can still erase
everything on the chip, including that "secure" flag. The chip says
that mass erase is permitted. Alas, it doesn't acknowledge or
execute the mass erase command.

So I spent some time trying to find out what I may be doing wrong,
but so far it seems that I'm doing everything right and that there's
something wrong with the chip.

Since desoldering the 48-QFN chip is a bit risky with the tools I
have, I want to be absolutely certain that the problem is not just
caused by some stupid bug in my program.

The plan is therefore to make a few "throw-away" boards to
experiment with the chip's protections and their removal, and see if
everything works as expected - including locking down the chip for
good. It's something that has to be done sooner or later anyway, but
I wouldn't have minded doing it later.

More about the throw-away boards in my next post.


One good thing that came out of all this is that I've cleaned up
libswd quite a lot. I also found that there's another project called
libswd, so I renamed my library swdlib for now - the whole package
will eventually need a better name, since it also includes a CC254x
debug/program library and also a tool that uses these libraries.

Despite all the cleaning, swdlib is still very unreliable: flashing,
say, a 16 kB firmware takes several attempts before it succeeds.
Strangely, everything appears to go well - I can read back and
verify all the settings before the last write that starts a Flash
write, but then the write ends in an access violation. It shouldn't
be able to do this at that point, yet it does. Very irritating.

If anyone wants to sink their teeth into the mysteries of SWD,
exorcising whatever is going wrong there would be a worthwhile task:
https://gitorious.org/anelok/anelok/source/swdlib

- Werner



More information about the discussion mailing list


interactive