2016-06-21 21:54 - Linux
I've been tweaking the setup of my home network recently, related to the building of my WiFi enabled temperature sensors. Two options for letting them exist in a self-sustaining way are mDNS and SSDP. I think I have mDNS working but I also wanted to try SSDP. After much looking I found that smcroute ("a command line tool to manipulate the multicast routes in the UNIX kernel") seemed to be what I needed.
But I'm running a quite old version of (a variant, actually, of) OpenWRT. I couldn't find a binary package that worked, so I built my own. I had to try several times before I got it to work. It was actually a linking error; the default instructions build much newer, incompatible, things than what I can use. But being a tiny embedded style system, when I built a "bad" binary and ran it, I'd only get "-ash: ./usr/sbin/smcroute: not found" even though the file was definitely there. Its dynamic library is what was missing!
On the off chance that somebody on the interwebs will find it useful, here's smcroute_2.0.0-1_ar71xx.ipk built for MIPS (Atheros AR71xx) and uClibc.
2016-06-05 18:37 - Making
I've had computerized logging of temperature, indoor and outdoor, since I lived in my previous apartment. Both the heat and A/C there was electric, which I paid for. With a clunky old unit. So I hooked temperature sensors to the server I ran all day anyway, and put a relay in front of the HVAC unit to create a simple thermostat. It's fun information to have, so I've kept it.
But they sensors are clunky wired units with some nasty quirks; for example on Friday it said the temperature inside remained exactly 77.1 degrees for about 20 hours straight. There are a couple spots that it will get "stuck" like that, and it limits the possibilities for me to lay things out (server + wire must reach out the window to keep outdoor data).
I've meant for quite some time to build something better. I have an esp8266 wireless unit bought on impulse lying around, at bottom left of the image besides this text. I've also got some DHT11 sensors I could hook up to it. Those are the little blue boxes in the top right, three in the tray they came in and one actively hooked up. And working!
But the DHT11 turns out to be awful. It only gives 1 degree Celsius resolution, so about two degrees Fahrenheit; I'd prefer something like 0.1 degree F resolution. It also does humidity which is nice, but with similarly lackluster abilities.
In my last electronics parts order I grabbed a few DS75 chips, which can do temperature to 0.0625°C resolution. It's sitting on the green board in the bottom right of the picture; next thing to do is to try to talk to it!
Update, on the 6th: I've got the DS75 hooked up and working and I can indeed get my 0.1°F or so readings out of it. I know for sure because I can watch it heat up a bit as I touch it with my finger, and cool off when I let go.
2016-05-16 21:19 - Making
I recently became the proud owner of a Raspberry Pi Zero. An amazing little gadget for its $5 price point! But as a result the features are a bit spare. When I found this RPi WiFi project on Hackaday I was hooked, I needed to have one. But it's not available, yet.
The original project is more ambitious than my adaptation of it. I only put the ESP module and a breakout for (power and) serial data. A stacking header mates with male header pins attached to the Zero, and voila! The original seemed to be called "WiFi Pants", with my simpler version intended to work with the Pi Zero, I chose to call mine "Zero Pants".
There's just one caveat: it doesn't start at boot. I'm pretty confident this is because I'm using the ESP-12-E module, which is set up with embedded flash and program to run. So I have to do the GPIO twiddle in step 10 of the instructions. But that causes a kernel panic. Actually what I need to do, so I have for now as a script file, is:
echo 0 > /sys/class/gpio/export
echo low > /sys/class/gpio/gpio0/direction
echo in > /sys/class/gpio/gpio0/direction
Remove the kernel module first, then toggle the GPIO pin to cause the ESP to restart. The module automatically reloads itself, and if you have a valid wpa_supplicant.conf set up, it connects in just a few moments.
Plus I needed to patch the esp8089 module to get it to compile for the recent kernel I got by following the instructions. (As mentioned in the comments.) But hey, it was a nice fun small project!
I ended up not installing either of the LEDs in this, the second module that I assembled. I got something wrong so the power LED was unnecessarily bright, and the "init" LED did indeed blink correctly to let me know the GPIO was twiddled. But it's normally high, so stays on the whole time, and also terribly dim, because it's being powered through the (I assume?) processor's internal pullup resistor. So no need to keep that!
2016-05-08 16:39 - Making
After quite a delay I'm continuing this series of posts.
I've learned that Samsung's SAM8 line of microcontrollers is based on the Zilog Z8:
Historically, the SAM8 and SAM88 CPUs that are the core of the S3 Family were based on Zilog’s efficient Z8 architecture. For Zilog to introduce the S3 Family is simply a natural evolution culminating in a cooperative agreement between IXYS and Samsung.
And that Zilog has purchased this line from Samsung to bring the product full circle:
IXYS Corporation, parent company of legacy and legendary microcontroller manufacturer Zilog, has entered into an agreement to purchase 4-bit and 8-bit Flash microcontroller product lines from South Korean semiconductor manufacturer Samsung Electronics for $50 Million.
This nugget of info helped me find the S3 Embedded Flash Serial Programming document (mirrored at archive.org and locally), which at first seemed very promising. The best I could find from the datasheet was vague references to "tool mode" which the TEST pin could set, but not whether it's active high or low, and also a NRESET pin with no polarity/value indication, and SDAT/SCLK which sounds like I2C. (The N in NRESET implies active low, and some vague wording implies active high for TEST, but that's not enough to go on by itself.) And no data about the protocol. But this S3 document from Zilog mentions pins with nearly identical names, has much more clear wording about the Reset and Test pins, and specifies the protocol to talk over the data line!
Unfortunately all my attempts to whip up something to talk to this chip with that protocol have failed. The Arduino is terribly easy to work with, but I've only got 5V modules, so I tried working with the 3V STM32 board I have instead. I might have been tripped up by the dual-direction data line (output at first to specify the operation, then input). Either way, I can't get the chip to respond.
Next up is the J6 header which just has two power pins and two UART interfaces. It took a little digging, but I found that UART1 spits out some data at power up, at 38400 N81; here's several repetitions:
00000000 00 00 55 49 42 30 01 0b 00 00 55 49 42 30 01 18 |..UIB0....UIB0..|
00000010 00 00 00 55 49 42 30 01 0b 00 00 55 49 42 30 01 |...UIB0....UIB0.|
00000020 18 00 00 00 55 49 42 30 01 0b 00 00 55 49 42 30 |....UIB0....UIB0|
By watching in my logic analyzer, I can see an 0x00, followed by an 8ms delay, then the 0x00 UIB0 0x01 0x0b, a 10ms delay, an 0x00, another 8ms delay, then the 0x00 UIB0 0x01 0x18. There's a clear pattern here, but I can't interpret the data. With the guts of the remote tacked down to the breadboard I can hardly interact with it. When I move it the backlight lights up, but I see no serial traffic. I can get to a few of the hard buttons beside the display, and they also have no effect.
The JTAG interface remains. But it will remain a topic for another day, as I've got learning to do before I have a chance of making progress.
2016-04-23 14:20 - General
I went out for lunch today, and chanced upon a street fair. One of the booths was selling framed art and I picked up Spiderman and the twin towers for only $10 each. After hanging them, my wall is getting pretty close to full!
2016-04-03 10:38 - Gaming
I've basically only played two games since Thanksgiving, first Metal Gear Solid 5 with almost 10 days of play time, and now Fallout 4, with over 5 days. Fallout is a more traditional game, so I know the amount of play time for the last save, but not any of the time spent and lost to reloading an old save, or the few times I intentionally rolled far back (including a bit to get 100% trophies. I continued for a while even after getting the platinum trophy, there were still new things to discover.
I had lots of fun but it's time to move on to working through my backlog of over 20 other games!
2016-03-09 22:14 - Making
For context see part 1, which has pictures and descriptions of the chips I'm referencing.
The important bits are two microcontrollers: one ARM made by ST, ("Chip 1") one 8-bit made by Samsung ("Chip 7"). I'll be referring to them as ARM and SAM8, respectively. Plus three connectors. There's J6 and J8, both close to the SAM8, both two by three standard 0.1" pitch headers, unpopulated. Then a completely unlabeled two by four arrangement of rectangular pads next to the batteries, far from any chips. I'm calling this one JX, for either eXtra or eXternal -- this one is accessible without disassembling the remote at all, just by opening the battery compartment. I've figured out what these all do, so let's share!
Just like J8 to come pin one is clearly marked as the singular square pad of the six, plus the notch on the silkscreen layout. Orient yourself so it's top left and I've chosen to label the pins counter-clockwise like a standard IC package. All of these are connected through to the ARM controller, like so:
|J6 Pin||ARM Pin|
I was quite confused for a while at the selection (port 1, pins 0 1 3 5, skipping 2 and 4??) for a while until I found, on pin 47 of its data sheet the alternate functions available on those pins, and the pattern seemed clear. I'm mildly surprised to see two UARTs broken out, perhaps the software dedicates one to sending and one to receiving, or command/debugging output, or some other combo? Or perhaps one is unused, "just in case" design. Certainly it will be interesting to check, but I doubt it will be much use on its own.
Also located just next to the SAM8, this is clearly a programming header for it:
|J8 Pin||SAM8 Pin|
Unfortunately data on this line of micros looks sparse. I can see these pin names, and a bare description of their function, in the data sheet, and it makes sense as a synchronous serial channel, and the TEST/nRESET pins to force it into programming mode. But what protocol goes over this channel? I surely don't know. The data sheet also has a surprising list of development tools listed, but none of them are common things. I could only find concrete evidence of one, a storefront with no price listed, which makes me think "If you have to ask how much it costs, you can't afford it." Certainly not for a hobby project! Slightly better news, I found concrete evidence of this particular micro model in use for other UEI remotes (specifically JP1.3). This is clearly the driver for the infra-red side of the remote, which works fine, so I don't need to mess with it. And maybe I can find some community reference, even if just source code, for how JP1.3 works, and maybe it's just the flashing protocol for this micro?
The main attraction was saved for last. Given the lack of markings I have to make up my own numbering scheme. So, with the remote oriented as pictured, see that it is two columns of four pads. Pin one is the top left, and they go counter clockwise from there. With that set, I can show the map to ARM pins:
|JX Pin||ARM Pin|
Jackpot! This is clearly the JTAG debugging header for the ARM micro! This is without a doubt the next area for me to concentrate on. I know what JTAG is, but so far very little about how it works. I've got an ST-LINK device, used for STM32 (ARM Cortext) work in the past which might be enough to move forward with. And if so that should give me full access to the ARM and whatever it has stored inside, plus I think I should be able to bit-bang SPI to the external flash chip as well, at least. I've mapped its pins to the SSP0 port on the ARM, no surprise, so it's accessible that way.
Fun aside: this had me very confused at first. For the lamest of reasons: I carefully counted out the pins and double-checked them all, thanks to the narrow pitch. I knew which went where for sure, looked them up and they made no sense. Only after a few back-and-forth attempts did I finally take notice of the "pin 1" marker on the chip. It's rotated 90 degrees counter-clockwise from the "natural" orientation. Compensate for that and the JTAG pins all jumped out.
2016-03-07 19:36 - Making
I've been a fan of JP1 Remotes for quite some time. There's a wonderful community that has written software to put the user in total control of all the features they make possible, and even written "extender" software to add additional features. My approach for some time has meant turning on all the right devices (player, TV, receiver) and set them all to the right inputs, at the press of one button. Then turn them all off with the press of another.
Most recently I've switched to the "Nevo C2" remotes (also known as "Xsight Color" or "ARRX15G"), which have a graphical display built in. This makes it easy for me to deal with the huge array (TiVo, HTPC, plus eleven game consoles) of devices I've got hooked up. The built in software is pretty good, especially with RemoteMaster to customize it. But it's pretty clunky in some areas. At one point I found a post with pictures of the inside of my remote. The post was meant to highlight the (very minor) differences between two similar models. In the full size image, one can just make out a big ARM chip in the middle. I got interested in discovering more about the innards of these things, and how hackable they could be with some reverse engineering. So I ordered an extra one to take apart and tinker with, with no worry of damage. (They can be found on eBay for around $16, so this isn't a huge investment.)
Just for posterity, here's the external view of the remote. Front, back, and battery compartment. Forgive the crappy shots, this isn't the interesting bit. Except the battery compartment, which shows eight exposed pads which are fully accessible, at the bottom of a rather deep/narrow opening. What exactly they're for is very much worth looking into. But what I really want to do is highlight the insides. It's a good thing I bought a sacrificial unit to do this with. I cracked about half of the clips off to get the thing open. Brittle plastic, plus I didn't know the layout. I also ended up ripping the leads right off of the piezo buzzer once the two halves finally separated.
First, here's a full shot of the immediately accessible (once opened) side of the PCB. The battery compartment is towards the left. On the far left are the previously mentioned exposed pads, plus a little circuitry which at first glance seems to be only related to the photodiode located there for learning capabilities.
The interesting bits are all at the other side, the right in this image. That area has been separately shot in a more close up view. I'm going to concentrate today on identifying the chips, so here's another copy of that image, with numbers overlaid for reference in the following commentary.
I've called out seven chips that seem especially interesting.
There's a large ARM logo at the top (with an "H" next to it), and STMicroelectronics logo at the bottom. The rest of the text reads:
KOR HP 948
This has got to be a STR911FAW42 chip which confirms that it's a 32 bit ARM MCU. The datasheet tells us that the 911FAW42 has 256+32 kB of flash and 92 kB of RAM, and comes in a LQFP128, which all seems right. Finding the programming pins, and ideally some spots that are more accessible than the tight pitch pints themselves, will be interesting.
This chip has no obvious (to me) markings besides the NXP logo which is upside down in this image. The text on it is:
This turns out to be a simple 74 series 74LVC(H)16373A: 16-bit D-type transparent latch with 5 V tolerant inputs/outputs; 3-state. A latch/flip flop. Curious.
This tiny chip is unreadable in the images so the text transcription will be extra important. By the look of it, an eight pin SOP, I'm guessing serial flash.
First, I see the second apparent date code: this 37th, chip 2 38th, week of 2009. As far as I know these remotes are discontinued, so it looks like I've gotten some "new old stock" here, which might help explain how cheap they are. Either way, this definitely looks like the 32Mb, 2.5V or 2.7V
Atmel DataFlash (Update: I had the wrong link, for part B not D here originally; Atmel doesn't have the D part on their site?!) by the part number on the second line. The remote supports adding custom icons, so the bulk storage in addition to the flash built into the MCU makes sense. This is the second part I'll be very interested to try to dump. It's probably wired straight to the MCU, but it's a much wider pitch part; I can solder breakout wires by hand without much fuss.
This chip is also small, and upside down in the image. A TI logo is visible. Its text is:
This turns out to be a SN74ALVC08 QUADRUPLE 2-INPUT POSITIVE-AND GATE, and the data sheet tells us that the top marking is indeed "VA08". The package lines up as well, so I have no reason to doubt this yet. The amount of glue logic is a bit surprising, though.
I've used an ISSI memory chip myself before, so I think I know what I'll find just by seeing the logo. But for completeness:
Yet another date code confirmation, this device is from late 2009 for sure. As suspected, this is a 64K x 16 HIGH-SPEED CMOS STATIC RAM, 1 megabit of RAM addressable as 16 bit words. I can probably ignore this chip. If I can dump and restore the firmware, I probably won't need to examine the expansion RAM. The bulk flash made sense, but I'm especially surprised to find a separate RAM chip on the board. I wonder what in the design necessitated this, that the RAM built into the MCU was insufficient?
I can see from a mile away that this is another standard series glue logic chip. The TI logo is visible in the corner, and the text:
We only need the second line to see this is a SN74LVC04A Hex Inverter. Nothing to say about that until I trace out where the connections are going. Physically it's between Chip 6 (RAM) and ...
This one's interesting! With my naked eye I can really only make out the bold Samsung mark. I need good lighting and magnification to make out the text:
This is as best as I can tell a S3F80KB 8-BIT CMOS MICROCONTROLLER, a secondary MCU‽ The plot thickens. Traces definitely must be found. What does this connect to, vs. the ARM MCU? Thankfully not terribly fine pitch, so again something I can work with. This is located towards the top, near the screen, is it related to that? There's also an obvious 8MHz resonator right next to it. Now I know why; I was surprised to see it before, when I saw what clearly seemed to be an SMD 24MHz crystal next to the main ARM MCU.
Near chip 7 are J8 and J6, two unpopulated 2x3 0.1" connectors. Near chip 1 is a metal tube, this is a tilt ball switch; the remote will (optionally) light up its display when moved.
I've got lots of things to do. An extra reason I wanted to order an extra remote to hack on is the firmware. All the ones I actively use are already in use, and I had to upgrade the firmware to be able to use them. I'm hoping to dump any contents of any flash memory on the device before ever plugging it in for real. There's a (mini) USB connector on the device (J1, near the bottom left of the close up view) for hooking up to a computer. I'd like to be able to compare the pre/post upgrade contents of the raw flash, plus make sure to monitor and log every possible (network, USB) interaction when upgrading the device. If I manage to do anything useful, it will almost definitely mean putting an alternate firmware together.
Figuring out where J6 and J8 go may prove enlightening/useful. Also the unlabeled exposed pads down by the batteries. There can't be much under the battery sticker, but some silkscreen markings are half covered at the edges, so perhaps something. Examining the other side of the board may be important as well, but these are tasks for another day!
2016-03-05 11:13 - Making
Just under twelve years ago, I bought a Braun 7505 electric razor. I like this thing. I've needed to replace the blades several times, of course, but overall it's worked very well over time without any issue. Except the batteries. One of my favorite features was the batteries, meaning it need be plugged in only to charge, not to use. But the batteries didn't last. I finally decided to see if I could do something about it.
At first I found only one relevant page online: How to change the batteries in a Braun 7505 Synchro Shaver. It complained of a bad similar explanation on eHow (which I've not read), which referenced a manual without any instructions. So I found the Braun SyncroPro Manual and indeed, it has no instructions to describe replacing the batteries. But the Korean Syncro Manual does have these instructions, on page seven.
I've reproduced that image on the right. It's got unrelated English text on the page, but it's a nice visual description of the necessary steps. I found that prying the outermost cap (step 2) works best by grabbing the inner edge of the opening for the plug. I couldn't (confidently) get something around the edge like pictured without damaging it. Once that cap is off, the sides come off easily by hand, and some T9 torx screws hold the back on. With that removed the power board comes right out, it's held in place only by the structure just disassembled.
The original batteries have tabs welded on, which are soldered into the circuit board. (Maybe Korean models aren't welded in, thus the instructions in their manual?) I popped the tabs off by prying with a knife, which damaged them only slightly. With some replacement (NiMH) batteries in hand, I cleaned their terminals and heavily tinned them with solder, then set them next to the tinned tabs, then heated the whole lot until the solder melted together again. The original batteries were also stuck down with adhesive; some hot glue took that place with my replacements.
After reassembly, I've finally got a cordless electric razor again! I delayed this repair so long, it will actually be hard to get used to.