From werner at almesberger.net Wed Oct 1 02:24:54 2014 From: werner at almesberger.net (Werner Almesberger) Date: Tue, 30 Sep 2014 23:24:54 -0300 Subject: KLtab: first two boards Message-ID: <20141001022454.GA32610@ws> Since KLtab is only 22 x 22 mm, one can fit four of them easily on a 5 x 5 cm piece of PCB. Here's an example with two of the four KLtabs assembled in the minimal configuration: http://downloads.qi-hardware.com/people/werner/kltab/tmp/kltab-minimum.jpg In the unpopulated circuits in the back one can see holes in the center pads. They were a misguided attempt of mine to properly solder that pad. Unfortunately, the holes are a bit too small to get anything useful done with them. I added a straightforward SWD-to-UBB pin assignment to the KLtab schematics (lower right corner): http://downloads.qi-hardware.com/people/werner/kltab/tmp/kltab-20140930.pdf And this is what the corresponding cable looks like: http://downloads.qi-hardware.com/people/werner/kltab/tmp/kltab-ubb-cable.jpg Apart from the center pad hole mishap, the KLtabs were as easy to make as expected, and they both identify nicely over SWD: http://downloads.qi-hardware.com/people/werner/kltab/tmp/kltab-identify.jpg - Werner From paul at kristianpaul.org Fri Oct 3 01:06:21 2014 From: paul at kristianpaul.org (Cristian Paul =?iso-8859-1?Q?Pe=F1aranda?= Rojas) Date: Thu, 2 Oct 2014 20:06:21 -0500 Subject: KLtab: first two boards In-Reply-To: <20141001022454.GA32610@ws> References: <20141001022454.GA32610@ws> Message-ID: <20141003010621.GA22149@micro> :-D From werner at almesberger.net Fri Oct 31 01:56:29 2014 From: werner at almesberger.net (Werner Almesberger) Date: Thu, 30 Oct 2014 22:56:29 -0300 Subject: Anelok: results of mixed goodness Message-ID: <20141031015629.GA1659@ws> I tortured the KLtab boards in many ways, but could never get them to behave like the chip on the non-programmable Anelok board #2. There is one thing that I didn't try yet, and that's completely locking down one of the chips on the KLtab boards. The reason is of course that this would make the board unusable - unless I implement some clever backdoor. But in any case, if the chip was protected that way, then it wouldn't indicate that it can be mass-erased, would it ? Well, I don't know for sure yet, but I noticed something else: a while ago, I had broken the build process of the boot loader in a way that would put incorrect data at the location of the all-important Flash security byte (FSEC). I reconstructed the likely version of the boot loader I had at that time, and found that FSEC was probably set to 0xed. This decodes to: 11 = backdoor disabled 10 = mass erase disabled 11 = Freescale access granted 01 = MCU security status is secure The backdoor is a mechanism that needs firmware support, so that wouldn't work with this broken boot loader, even if I had implemented such support (which I haven't). All other settings are such that I can't get in :-( This still doesn't explain why the chip happily announces that it could be mass-erased, but all the other clues are there. So the next step will be to try to unsolder it and replace it with a new one. Let's see how much damage that does ... Oh, and in completely unrelated news, my Ben-based SWD programmer now requires the user to announce explicitly what protection level the binary about to be flashed will set. If there's a mismatch, it will politely refuse to mess things up. - Werner From werner at almesberger.net Fri Oct 31 02:09:11 2014 From: werner at almesberger.net (Werner Almesberger) Date: Thu, 30 Oct 2014 23:09:11 -0300 Subject: KLtab: becoming a programmer Message-ID: <20141031020911.GB1659@ws> To eliminate the risk of there being an unexplained and unobservable interaction between the reluctant board and the Ben (acting as programmer), I also tried to replace the Ben with something else. Since I had a bunch of bored KLtabs at my hands, the choice of that "something else" was easy. Also, the programming/testing fixture for Anelok will be able to program the boards it is working on, so I'll need to have my own programmer solution by then anyway. Just didn't expect to have to implement it so soon ... Anyway, I cleaned up swdlib such that it can run on a KL2x and added a simple USB-based interface. A few things don't work reliably yet and signal integrity seems to be quite horrible, but it's getting there. This is what a KLtab programming another KLtab looks like: http://downloads.qi-hardware.com/people/werner/anelok/tmp/kltab-pgm.jpg swdlib is still in the Anelok repo (will move out some day): https://gitorious.org/anelok/anelok/source/swdlib The KLtab firmware is here: https://gitorious.org/anelok/kltab/source/fw And the rather primitive user-space tool is here: https://gitorious.org/anelok/kltab/source/tool I may eventually convert all this to be DFU-based, but the proprietary protocol is more convenient for now. Warning: this one doesn't have the FSEC sanity check yet. So if you play with it, check your binaries first ! :) - Werner