Category Archives: hardware

More arm android box conversion adventures

TL;DR: Still failing. Gave up again.

Back when I bought a RK3066 based device, I had seen rockchip developers start contributing directly upstream.  However, the RK3066 just missed the boat, and while I poked and prodded a bit, it was all just a bit too difficult and a bit too complicated a bit too much not much fun.  Still, I followed what was going on.  The plan was to use the swell of consumer electronics to get a cheap android tv box that I could run linux on, and use as a small home server.  “Just use a raspi” you say.  Well, no.  Raspi3 is at least decently powerful, but running everything off a sdcard, and not having a case is really not what I was looking for.  Little tiny cute black boxes, with a remote control and a power supply and ethernet and usb shipped for $30?  That’s what I want to reuse.  Rockchip continued to contribute upstream, so I bought a MXQ 4K (RK3229).  New hotness I thought, but the cheap end.  I still believed that rockchip was doing the best job of upstream support.  Note: My copy of this device has a much smaller heatsink, Spectek flash, not Sandisk, and some generic no name ram chips. (See pics)

Top side, smaller heatsink, no name ram.

Top side, smaller heatsink, no name ram.

Maybe they are.  And I’ve not worked on amlogic or sunxi chips, but goddamn, the work environment is still just as sucky.  A garbage world of “custom roms” and complicated documentation detailing multiple ways of doing things with rarely any explanation of why.  I’ve still no idea, but some things seem a little clearer than last time… maybe?

If you just want to run linux, in _theory_ you can just use the existing android kernel shipped stock.  It has support for all your hardware, you just need to replace the root file system (RFS) and amend the kernel command line to say where your rootfs is.  Except, because some of the drivers are actually separate binary proprietary modules, you end up needing a fucking initrd/initramfs timewaste so it can have such core details like a functional fucking nand driver.  Why the fuck rockchip is keeping _this_ bit proprietary is beyond me.  So that gets non-trivial quickly.  You can in theory extract the modules from your android system image.  If you have a stock firmware, (“update.img”) you can use rkunpack from the rkflashtool repository.  you’ll probably have to unpack more than once.  Documentation on what’s what is less than forthcoming.  The “system.img” wil be a raw ext4 image (in theory) and you can mount it locally to explore with “sudo mount -o loop blah.img somemountpoint”

anyway, while some of this is just for my own notes, not really for anyone else, one thing has stuck out.  First, the default serial console is at 1500000 baud.  Thanks for nothing rockchip.  On a cp2102 serial dongle, you’ll need to use the silabs baud rate aliasing software to get to this baud rate.  Thanks for nothing silabs. and yeah, again, thanks for nothing rockchip.  The serial console is in the picture below.

Bottom side, spectek flash, serial console details

Bottom side, spectek flash, serial console details

Oh yeah, the “thing that has stuck out”  Despite being “unbrickable” because they have a maskrom bootloader, and normally just going into recovery mode,  I’ve had great difficulty.  After some bad flashing,  (bad why? no idea, rkflashtool or upgrade_tool both successfully report the flashing complete, then I reboot, and get…. bad things) the serial console will hang on a line like…

In
300MHz
DDR3
Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB
mach:2
OUT
Boot1 Release Time: 2016-03-15, version: 2.31
ChipType = c 275
No.1 FLASH ID:2c 64 64 56 a5 4
ECC:60
ReadRetry pageadd=15d800  ecc=3c err=ffffffff
Read pageadd=15d800  ecc=3c err=ffffffff
spare: 0x0:b8679151 b8679151 b8679151 b8679151 
ReadRetry pageadd=15d801  ecc=3c err=ffffffff
Read pageadd=15d801  ecc=3c err=ffffffff
spare: 0x0:527ded0c 527ded0c 527ded0c 527ded0c 
SdmmcInit=0 20
StorageInit ok = 134644
SecureMode : SBOOT_MODE_NS
powerOn 812121
Usb re Boot. 6812118

At this point, rkflashtool v will “fail” like so… (notice mangled text)

$ rkflashtool v
rkflashtool: info: rkflashtool v5.2
rkflashtool: info: Detected RK322X...
rkflashtool: info: interface claimed
rkflashtool: info: chip version: 322A-��..��-��

upgrade_tool will still say the device is connected, in “Loader” mode, and TestDevice, ReadFlashID, ReadFlashInfo and ReadChipInfo all still work. But attempting to download any image will fail saying parameter is invalid. rkflashtool p agrees.

 rkflashtool p
rkflashtool: info: rkflashtool v5.2
rkflashtool: info: Detected RK322X...
rkflashtool: info: interface claimed
rkflashtool: info: reading parameters at offset 0x00000000
rkflashtool: info: size:  0x0000ffff
rkflashtool: fatal: Bad parameter length!

One time this happened, I got out of it by having the USB-A-A cable disconnected (oh yeah, A-A for OTG? thanks for fucking nothing rockchip, hooray port overloads and reverse powering disasters) holding the recovery button down (with a toothpick down the SPDIF hole. (button down the AV hole _should_ be different but seems to behave the same for me)) and then plugging in the main power supply. Perhaps it had been a problem with powering the device purely via the A-A cable as I’d normally been doing?

Who knows. It’s currently in this state again, the unbrickable “bricked” Even shorting pins 7-8 on the NAND chip itself and powering up isn’t helping. (The “standard” rockchip method of getting back to maskrom mode) I get a different log, but it’s still non-responsive, even after inserting the A-A cable. (Still in loader, but not really working)

DDR Version V1.04 20160504
In
300MHz
DDR3
Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB
mach:2
OUT
Boot1 Release Time: 2016-03-15, version: 2.31
ChipType = c 276
No.1 FLASH ID:2c 64 64 56 a5 4
FlashLoadPhyInfo fail 2bc!!
sync para 32
sync para 32
ECC:60
ReadRetry pageadd=15d800  ecc=3c err=ffffffff
Read pageadd=15d800  ecc=3c err=ffffffff
spare: 0x0:b8679151 b8679151 b8679151 b8679151 
ReadRetry pageadd=15d801  ecc=3c err=ffffffff
Read pageadd=15d801  ecc=3c err=ffffffff
spare: 0x0:527ded0c 527ded0c 527ded0c 527ded0c 
SdmmcInit=0 20
StorageInit ok = 93093
SecureMode : SBOOT_MODE_NS
powerOn 770567
Usb re Boot. 6770565

So. No results, no future, but at least a weird log for the internet to archive if it helps anyone sometime.

Using NetBeans for STM32 development with OpenOCD

This post supersedes http://false.ekta.is/2012/05/using-netbeans-for-stm32-development-with-stlink-texane/ it has been updated for 2016 and current best software tools.  Again, this is only focussed on a linux desktop environment.

Required pieces haven’t changed much, you still need:

  1. A tool chain.
  2. GDB Server middleware (OR just a tool flashing if you want to live in the dark ages)
  3. A “sexy” IDE (If you disagree on wanting an IDE, you’re reading the wrong post)

Getting a toolchain

New good advice

Advice here hasn’t changed.  The best toolchain is still gcc-arm-embedded  They steadily roll out updates, it’s the blessed upstream of all ARM Cortex GCC work, and it has proper functional multilib support and proper functional documentation and bug reporting.  It even has proper multi platform binaries for windows and macs.  Some distros are packaging “arm-none-eabi-XXXXX” packages, but they’re often old, repackages of old, poorly packaged or otherwise broken.  As of November 2015 for instance, ArchLinux was packaging a gcc 5.2 binary explicitly for arm-cortex, that did not support the -mmcu=cortex-m7 option added in gcc 5.x series.  Just say no.

I like untarring the binaries to ~/tools and then symlinking to ~/.local/bin, it avoids having to relogin or start new terminals like editing .bashrc and .profile does.
~/.local/bin$ ln -s ~/tools/gcc-arm-none-eabi-5_2-2015q4/bin/arm-none-eabi-* .

Old bad advice

The internet is (now) full of old articles recommending things like “summon-arm-toolchain” (Deprecated by the author even) “code sourcery (lite)” (CodeSourcery was bought by Mentor, and this has been slowly killed off.  Years ago, this was a good choice, but all the work they did has long since been usptreamed)  You can even find advice saying you need to compile your own.  Pay no attention to any of this.  It’s well out of date.

GDB Server middleware

New good advice

Get OpenOCD. Make sure it’s version 0.9 or better. 0.8 and 0.7 will work, but 0.9 is a _good_ release for Cortex-M and STM32 parts. If your distro provides this packaged, just use it. Fedora 22 has OpenOCD 0.8, Fedora 23 has OpenOCD 0.9. Otherwise, build it from source

Old bad advice

Don’t use texane/stlink.  Just don’t.  It’s poorly maintained, regularly breaks things when new targets are introduced and not nearly as flexible as OpenOCD.  It did move a lot faster than OpenOCD in the early days, and if you want a simpler code base to go and hack to pieces for this, go knock yourself out, but don’t ask for help when it breaks.

Netbeans

No major changes here, just some updates and dropping out old warnings.  You should still setup your toolchain in netbeans first, it makes the autodetection for code completion much more reliable.  I’ve updated and created new screenshots for Netbeans 8.1 the latest current release.

First, go to Tools->Options->C/C++->Build Tools and Add a new Toolchain…

Adding a new toolchain to netbeans

Adding a new toolchain to netbeans

Put in the “Base directory” of where you extracted the toolchain.  In theory netbeans uses the base directory and the “family” to autodetect here, but it doesn’t seem to understand cross tools very well.

Base path for new toolchain and name

Base path for new toolchain and name

Which means you’ll have to fill in the names of the tools yourself, as shown below.  Click on “Versions” afterwards to make sure it all works.

Adding explicit paths to netbeans toolchains

Adding explicit paths to netbeans toolchains

“Versions” should show you the right thing already, as shown

Versions from our new toolchain (and an error from gdb we must fix)

Versions from our new toolchain (and an error from gdb we must fix)

If you’re getting the error about ncurses from gdb, this because newer gdb builds include the curses “tui” interface to gdb in the standard build.  (Yay! this is a good thing!)  However, as the g-a-e toolchains are all provided as 32bit, you may be missing the 32bit ncurses lib on your system.  On Fedora, this is provided in the ncurses-libs.i686 package.

Ok, now time to build something.  This is your problem, I’m going to use one of the libopencm3 test programs right now, specifically, https://github.com/libopencm3/libopencm3/tree/master/tests/gadget-zero (the stm32l1 version)

Programming your device

Netbeans doesn’t really have any great way of doing this that I know of.  You can use build configurations to have “run” run something else, which works, but it’s a little fiddly.  I should spend more time on that though.  (See later for a way of doing it iteratively via the debugger console in netbeans)

In the meantime, if you just want to straight out program your device:

$ openocd -f board/stm32ldiscovery.cfg -c "program usb-gadget0-stm32l1-generic.elf verify reset exit"

No need for bin files or anything, there’s a time and a place for those, and if you don’t know and can explain why you need bin files, then elf files are just better in every way.

Debugging your part

GDB is always going to be a big part of this, but, assuming you’ve got it flashed, either by programming as above, then you can debug in netbeans directly.  First, make sure OpenOCD is running again, and just leave it running.


$ openocd -f board/stm32ldiscovery.cfg

First, install the gdbserver plugin, then choose Debug->Attach Debugger from the menu.

Attach to a gdbserver

Attach to a gdbserver

  • Make sure that you have “gdbserver” as the debugger type.  (Plugin must be installed)
  • Make sure that you have “ext :3333” for the target.  By default it will show “remote host:port” but we want (need) to use “extended-remote” to be able to restart the process. (See the GDB manual for more details)
  • Make sure that you have the right project selected.  There’s a bug in the gdbserver plugin that always forgets this.

At this point, “nothing” will happen.  If you look at the console where OpenOCD is running, you’ll see that a connection was received, but that’s it.
Press the “Pause” button, and you will stop execution wherever the device happened to be, and netbeans will jump to the line of code. In this example, it’s blocked trying to turn on HSE, as there’s no HSE fitted on this board:

Source debugging in netbeans via OpenOCD

Source debugging in netbeans via OpenOCD

If you now set a breakpoint on “main” or anywhere early and press the “Restart” icon in the top, OpenOCD will restart your process from the top and stop at the first breakpoint. Yay!  If restart fails, make sure you used “extended-remote” for the target!

Bonus

If you click the “Debugger console” window, you can actually flash your code here too.  Leave the debugger running!  (No need to stop the debugger to rebuild) Make a change to your code, rebuild it, and then, on the “Debugger console” just enter “load” and press enter.  You’ll see the OpenOCD output as it reflashes your device.  As soon as that’s done, just hit the “Restart” icon in netbeans and start debugging your new code!

Cypress CY8CKIT-059 PSoC 5LP proto kit – first impressions

Love the packaging! I got this CY8CKIT-059 PSoC 5LP proto kit, and the CY8CKIT-049-42xx, the PSoC 4 proto kit, as they’re both super cheap, and they both came in rather excellent packaging. The pcb is behind a peel off window, in a cutout of a sandwich of three sheets of corrugated cardboard. The backside has a nice graphical layout with pins labelled, and some basic info on where to get more info. Very nice, compact, easy to ship, well done Cypress.
cypress-kit-edge-on_sm

cypress-kit-backside_sm

cypress-kit-front_sm

Of course, that’s about all that’s nice. The PSoC family seems interesting, I’ve been wanting to play with them for a while, but Cypress has absolutely zero linux support, and because of the configurable nature of the device, you really do seem to need to use their windows PSoC Creator tool. Allegedly once you’ve designed your system, you can edit the code portions freely, but it seems a long way off. OpenOCD has support for the flash in the PSoC 4 family, but nothing (yet) for the flash, and definitely no support for the KitProg programming dongle. That KitProg does seem like a nice bit of gear in it’s own right though, it’s USB2I2C, USB2UART, SWD debug adapter, on a little snap off portion of the board. However, even the USB2UART portion fails to be recognised as CDC-ACM in linux, presumably due to a bug in the descriptors. lsusb implies that they’re trying to be CDC-ACM. This one will have to be on the shelf for quite a while I’d imagine.

Full lsusb output for posterity here:

Bus 003 Device 011: ID 04b4:f139 Cypress Semiconductor Corp. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 ?
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0         8
  idVendor           0x04b4 Cypress Semiconductor Corp.
  idProduct          0xf139 
  bcdDevice            2.0b
  iManufacturer           1 Cypress Semiconductor
  iProduct                2 Cypress KitProg
  iSerial               128 1C210338012E4400
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          130
    bNumInterfaces          4
    bConfigurationValue     1
    iConfiguration          2 Cypress KitProg
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              400mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              3 KitBridge
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.11
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      43
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              5 KitProg Programmer
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
    Interface Association:
      bLength                 8
      bDescriptorType        11
      bFirstInterface         2
      bInterfaceCount         2
      bFunctionClass          2 Communications
      bFunctionSubClass       0 
      bFunctionProtocol       0 
      iFunction               0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      0 None
      iInterface              4 KitProg USBUART
      CDC Header:
        bcdCDC               1.10
      CDC ACM:
        bmCapabilities       0x02
          line coding and serial state
      CDC Union:
        bMasterInterface        2
        bSlaveInterface         1 
      CDC Call Management:
        bmCapabilities       0x00
        bDataInterface          1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval               2
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              4 KitProg USBUART
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x86  EP 6 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x07  EP 7 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)
$

The KitProg also has a bootloader of some form, if you hold down reset while plugging it in, though it times out and reboots normally after a couple of seconds idle.

Bus 003 Device 012: ID 04b4:f13b Cypress Semiconductor Corp. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x04b4 Cypress Semiconductor Corp.
  idProduct          0xf13b 
  bcdDevice            1.00
  iManufacturer           1 Cypress Semiconductor
  iProduct                4 KitProg Bootloader
  iSerial               128 1C210338012E4400
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           41
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          2 Configuration 0x0001
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              3 Interface 0x0001
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.11
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      36
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
Device Status:     0x0000
  (Bus Powered)

SiLabs EFM32 Happy Gecko starter kit – first impressions

More unboxing. It includes a CR2032 coin cell in the box. Handy when the product line’s premise is ultra low power. It includes two usb cables, one mini, one micro. What the hell. why are you using mixed connectors?! (One for debug, one for user, similar to the original STM32F4 discovery)

Nice looking board, nice screen. Factory demo software is space invaders! Nice demo of touch buttons, physical buttons and the screen. Startup screen shows the debugger state as well. Expansion header seems to have a full silkscreen with correct positioning. Debug connector for connecting your own debug hardware is the full ARM Cortex with trace header, 2×10@1.27mm pitch. This is somewhat unusual, I’ve never had one that broke out the full ETM pins.

The kit user guide implies that there’s a USB flash drive in the box, containing simplicity studio. Thankfully that’s not the case. That would have been really wasteful. (Yes, yes, helpful for some people with shitty internet, but incredibly wasteful for everyone else)

The onboard JLink OB also presents a mass storage device, with a (broken) mbed link, a link to the starter kit’s home page, and a link to simplicity studio’s homepage. Rather shitty filenames, but I guess that helped someone’s day :) Bit lame about the mbed link not working though. It looks like something that mbed setup to be permanent, but someone overlooked somewhere: http://mbed.org/device/?code=200501120000B7A4D74B847B (Update: It might actually work, but mbed’s website was hacked at the time of writing….)

The rest of the kit user guide doc is rather sparse, (to be polite) simply containing some screenshots of how to run demos and get more information from within Simplicity studio. The kit home page does have a link to download the schematics though, that’s nice.

Doesn’t work with OpenOCD at the time of writing, but very basic preliminary support is proposed in http://openocd.zylin.com/#/c/2931/

Atmel SAMD10 Xplained mini board review

Got a pile of dev boards for some testing. Some first impressions of the ATSAMD10-XMINI. First off, it’s nice and cheap, $9 or so. Comes in a really small cardboard box, with absolutely no documentation beyond some links on the box. Totally fine, no need for anything else these days. The board is a somewhat unusual shape, with the micro usb connector for the onboard DDBG (CMSIS-DAP) protruding out the back. Whatever. At first glace, the board appears well labelled. A closer glance….. well…

The user guide for this board refers to all the headers as JXXX. The J number is NOT in the silk on the board. The userguide has a picture of the board, and marks some of the J headers, but not all. The rest you have to just sort of figure out. This seems like a really amateur oversight. Fixing the silk would have been ideal, but at least the documentation could have a better overview of the board! (The userguide does manage to include screenshots of how to install atmel FLIP, which seems like a total waste of space for this document)

The user guide refers to the pins with J200-1, -2, -3, etc. The silk on the pad arrays is just numbered 1..5, and A..P. There’s silk on the back describing some pins, no idea why some and not others. There’s a big box of silk on the back that seems to be describing some pins, but no idea which, or what order.

There’s a specially boxed off section of pads in the top right, 2×10. It’s unlabeled. No idea what it’s for. (Update, turns out this is for Xplained Pro addons, the userguide covers this, and actually uses the grid array notation that matches the board.)

The user guide does (un)helpfully include arduino pin numbers, for the arduino compatible pin arrays, but there’s no mention of arduino software, or linked anywhere, so who cares about that. The column in the table that includes this is unlabeled as well.

The factory firmware is a morse application. Connecting to the CDC-ACM uart provided by the EDBG module lets you blink out letters, and tapping in keys on the user button prints them to the uart. It resets every few seconds idle and prints some help text. Neat enough.

The user guide does NOT include the schematic of the board. This is a serious omission. Particularly given the poor documentation/silk screen match up, but also as these boards are often used as examples for your own projects. A snippet of the power supply section is included, but again, the labels don’t match the board. I went back and forth through the user guide a few times to make sure I wasn’t missing anything. However, the software package download, which I skipped initially, actually includes no software. It includes all the schematics and proper board diagrams that should have been in the user guide. Pretty poor form Atmel :|

No comments on the tools or device itself yet, that’s for a much later date :)

Terminus Tech 7 port usb 2 “high speed” hub teardown

7 port usb 2.0 “high speed” hub, with per port power switches and leds. Only shows up as full speed in lsusb. Leds on ports are very bright, power switches only cut vbus line, rather flaky construction, shaking or bumping can cause disconnects. Seems to consume too much power, without external 5V (not included) vbus can be very low. Available on ebay, tmart, dx.com… http://www.ebay.com/itm/371304833792

The fe1.1s chips are meant to support high speed, so…?

Update: When I had it open, connected to a different computer, it showed up reliably as high speed. Back on the original computer, disassembled, still high speed. Case closed up again, it would show up normally as full speed fallback, and only occasionally as high speed. Further testing indicated that the front panel usb socket is the actual cause. Connecting this hub to another high speed hub showed up reliably as high speed.

The sexy input cap is 200uF, 10V. The rocker switches are KCD11, rated 3A 250VAC, or 6A, 125VAC! The crystal is umarked, but must be 12Mhz from the datasheet.

2015_06_17-14_30_42--img_9408_JFR

2015_06_17-14_30_37--img_9407_JFR

2015_06_17-14_30_00--img_9406_JFR

Carlo Gavazzi EM210 coupled display panel teardown

The Carlo Gavazzi EM210 series [1] of 3 phase energy meters have a rather neat feature. You can mount them on a DIN rail or panel mount, with the same unit, and the display portion is simply detachable, and plugs back in on the reverse side. This is neat tech, and probably saves on inventory in a few distributor places at least, though I don’t imagine it makes any real difference for the end user, who will mount it once and leave it. Still, the display piece has the control buttons and the LCD display, no batteries, and no contacts. So I pulled it apart :)

I don’t know how it works really, it’s presumably the same method as NFC, by modulating the power draw from a capacitively or inductively coupled connection. It’s cool though. ATMega169 for the LCD control and buttons. Not entirely sure what the crystal is for, it’s marked “KDS3C” but I didn’t look further for a speed marking. Presumably you need a proper crystal to be able to synchronize the coupled connection properly? I don’t believe it’s an RTC crystal, as this is the detachable display portion. I always like seeing cutouts mid PCB for inserting big components.

The trimpot is an interesting idea. It’s used as a “lock”. With it turned all the way one way, the device is considered locked, and this screw access is on the back of the display portion. This portion also has tags for tamper seals, so I guess that’s one way of doing it on the cheap? Presumably just an ADC input to determine lock status.

The oddly slanted through hole parts on the left are the front panel buttons, nice alignment :)

ATMega169 for LCD control, coupled connection

ATMega169 for LCD control, coupled connection

[1] I’d link to them, but their website is junk and doesn’t let you link to products, and requires sign up to get a datasheet, that uses old names. The same sort of stupid games with redirecting you to different websites for different markets for the same device and all the usual terrible product management choices that lead engineers to ignore your products.

minix neo x5 mini – backup partitions and investigate

Urgh, I hate the massive pile of rom noise around anything to do with android devices.

I’m using https://github.com/neo-technologies/rkflashtool because it appears to be actually maintained. https://github.com/linuxerwang/rkflashkit is also somewhat convenient, though it’s gui only. If it was a nice python tool with a gui front end that would be even better. (no idea why you need waf and install either, simple “python run.py” is perfectly suitable.) libusb+python is perfectly acceptable for this sort of thing. No idea why people went straight to C code. https://github.com/neo-technologies/rockchip-mkbootimg looks good too, but I’ve not poked it yet. Anything that’s being maintained basically.

A commonly referred tool, https://github.com/naobsd/rkutils while often pointed to, is effectively a dead end with zero follow up commits. I’ve no interest in following that nest of forks.

Anyway, here’s the bits that actually worked to open up the boot partition image extracted with either rkflashkit or rkflashtools…

  • ./rkflashtool r boot > boot.img
  • dd if=boot.img of=bootimg.gz skip=8 bs=1 count=20000000
  • mkdir hohoho && cd hohoho
  • gunzip < ../bootimg.gz | cpio -i --make-directories

According to this review of boot.img formats, this means the x5mini uses format 4.

karlp@teros:~/projects/rkflashtool/hoho (master)$ ls
charger       init.goldfish.rc       init.usb.rc               sbin                 ueventd.rk30board.rc
data          init.rc                proc                      sys
default.prop  init.rk30board.rc      res                       system
dev           init.rk30board.usb.rc  rk30xxnand_ko.ko.3.0.36+  ueventd.goldfish.rc
init          init.trace.rc          rk30xxnand_ko.ko.3.0.8+   ueventd.rc
karlp@teros:~/projects/rkflashtool/hoho (master)$ 

Still learning the pieces, this is as much diary as blog.

Minix NEO X5 mini – teardown and serial console

Well, I bought a “Minix NEO X5 mini” for various experiments, eventually planning just a plain linux server, with ethernet and wifi, and a pile more ram and flash than the regular OpenWRT router platforms. I chose this based mostly on the smallest, cheapest that had a physical ethernet port. The other contender was the UG008. (And UG008B) Those are marginally smaller, and have one less fullsize USB, also, I _thought_ I’d read good instructions on getting linux running on the x5mini, but it turned out the instructions were for the x5 (full size) which is very similar, but not the same. I’ve since found instructions for the ug008, maybe I should have bought that. It also has a power button and from the pcb pics, looks like the pads for test points are bigger. No heatsink though, and I’d heard it’s wifi wasn’t as good. (Rumous and hearsay, I’ve no idea really) The second fullsize USB port however, is kinda of interesting. The x5mini came with a rather unusual fullsize USB A male-male cable. And there’s no microusb port for the OTG like normal. Plugging this in to a regular pc host would be disastrous, so the supplied android has a special menu option to enable “connecting to pc” which resets on every boot. If you do have it turned on, and you push the pinhole on the bottom while plugging in the power, you’ll get a usb device that ADB can find. dodgy, a regular OTG port would have been preferable.

So yeah, it works pretty well out of the box, but there’s enough reviews of that. We’re here to pull it apart. The little screws are glued in, so you need a good screwdriver, I almost stripped them getting them out. Then, whee, brown PCB! And whee, they put a weight in it to feel pro ;)

The wifi (rtl8188es) antenna is soldered on, then soldered to an adhesive antenna on the lid, a little awkward, but perfectly reasonable of course. Immediately on the board you can see two missing ICs, one, labelled “WIFI2” is almost certainly Bluetooth, which is not on the x5mini, but is on the x5. More curious though is missing QFP48 IC by the recovery button, and it’s 12 pin “STM_DEBUG” connector. It certainly reminds me of an STM32 footprint, though the debug for cortex-m is normally 10 or 20 pins, not 12? No idea. Two test points on this side, T23 and T24, if it’s indeed a bluetooth module, this is possibly a uart between them? *shrugs*

Back to the “top” side, ethernet is an SMSC LAN8720A, power is a TI T659102, which seems to be pretty common on these boards. There’s two filled jumper blocks with interesting text, “USB1 Device / USB1 Host” and “Auto power on enable/disable” but I’ll leave them for a later time. There’s a rather unexpected battery connector too. Minix doesn’t have any battery backed devices in their catalog, so someone’s design company has been working on this. So much for thinking that minix was an OEM.

T306 is RX, T307 is TX and T308 is GND, for a serial console at 115200, 8N1

minix-neo-x5-mini-pcb-top-notes-30
minix-neo-x5-mini-pcb-bottom-notes-30

Finally, here’s most of the bootup

STM32 Unique ID Register on L1 parts

Last week I mentioned I was seeing duplicate “Unique” ID registers on some STM32L151 parts [1], and included some memory dumps of the three unique ID registers as proof.

However, I had foolishly assumed that on the L1 the Unique ID register was three contiguous 32 bit registers, as it is on the F0, F1, F2, F3 and F4. (The base address changes, but that’s normal and expected)

On the L1, the registers are actually at offset 0, offset 4, and offset 0x14. Thanks for nothing ST! :(
(Oh, and L1 Medium+ and High Density devices use a different base address too, good job)

Here’s some more complete memory dumps for the same three parts I was looking at last week.

UID31:0 UID63:32 UID95:64
Part A 0x0e473233 0x30343433 0x00290031
Part B 0x0e473233 0x30343433 0x00320032
Part C 0x0e473233 0x30343433 0x00380030

Reading other reference manuals, and seeing that the UID registers often have 8 bits of unsigned “Wafer number”, 7 bytes of ASCII Lot number, and 4 bytes of X/Y wafer coordinates in BCD, I would interpret my part “A” above as

Wafer Number Lot Number X/Y coords
Hex 0x0e 0x47323330343433 0x00290031
Natural 0x0e G230443 X=0029, Y=0031

For reference, here are some full dumps of that section of memory. “0x7b747800” is what I had been looking at as UID bits 95:64, note that there are other bits in this section with fixed values, no idea what they mean :)

Part A

(gdb) x /20x 0x1FF80050
0x1ff80050: 0x0e473233  0x30343433  0x7b747800  0x50505091
0x1ff80060: 0x00000011  0x00290031  0x11000000  0x11000011
0x1ff80070: 0x00000000  0x00000000  0x029f067e  0x035a0000
0x1ff80080: 0x035a0000  0x035a0000  0x035a0000  0x035a0000
0x1ff80090: 0x035a0000  0x035a0000  0x035a0000  0x035a0000
(gdb) 

Part B

(gdb) x /20x 0x1FF80050
0x1ff80050: 0x0e473233  0x30343433  0x7b747800  0x50505091
0x1ff80060: 0x00000011  0x00320032  0x11000000  0x11000011
0x1ff80070: 0x00000000  0x00000000  0x02a50685  0x035e0000
0x1ff80080: 0x035e0000  0x035e0000  0x035e0000  0x035e0000
0x1ff80090: 0x035e0000  0x035e0000  0x035e0000  0x035e0000
(gdb)

Part C

(gdb) x /20x 0x1FF80050
0x1ff80050: 0x0e473233  0x30343433  0x7b747800  0x50505091
0x1ff80060: 0x00000011  0x00380030  0x11000000  0x11000011
0x1ff80070: 0x00000000  0x00000000  0x02a50689  0x035e0000
0x1ff80080: 0x035e0000  0x035e0000  0x035e0000  0x035e0000
0x1ff80090: 0x035e0000  0x035e0000  0x035e0000  0x035e0000
(gdb)

[1] Again, these are STM32L151C6T6 parts, revision V, package markings “GH254 VG” and “CHN309”