Category Archives: hardware

Nitsuka DX2E office phone teardown.

Full model on back of phone: DX2E-12BTXH. Manufactured October 1999. Internal PCB is clearly multi model, and also has the model MH 6330(1) and DX7C-12ANU5-A1
I have a few of these, they’re quite common, you can buy them on ebay for ~$35 or so, or similar models. I had the (very silly, but there was going to be some learning involved) idea of turning one of them into …. a phone. The plan is/was to hookup my own hardware to the handset, buttons and lcd screen, a little linux SoM or similar, and have it run some SIP softphone, running off 18650 batteries. Basically, make a phone…. into a phone. Not all terribly complicated, really.

So, time to open it up. Immediate difficulties are that the entire phone body is a giant PCB with button press pads. I’d loosely been planning on making a little USB HID device to capture all the buttons. (As we’re making a softphone, we don’t need DTMF or anything silly) Gonna have to rethink that now :) Anyway, what’s inside? Super easy to open, plain phillips head screws, no glue, no latches.

Three major ICs, the LCD connector, and the wonderful world of PSTN power supplies.

Let’s start at the top.

X2 is labelled Mitsubishi, M38003M6, and is by all accounts, a mask rom H8/300L series. Part numbers match up for Renesas (the current owner at least) I suspect this is handles all the programmable buttons and the LCD? X1 is a bit of a mystery, it’s labelled NEC D65825GF043. No idea what this is. Custom asic for phones? *shrugs*
Down to the bottom…

X3, Toshiba TC35324F. I found TC35300 and TC35310, both DTMF decoders. I suspect that this listens in on it’s own keypad? Seems a bit excessive though?

X7 (what happened to X4/X5/X6) Is a plain old MC34119. An audio amplifier. The fun things with old tech like this, it talks about being “low current” with only 2.7mA Iq, suitable for batteries :) The datasheet I found even excitedly mentions that it contains 45 active transistors! Whee.

Finally, back side. Just keypads and LEDs really.

Anyway. There it is. Not really sure what next. It wouldn’t be completely unreasonable to just make a whole new pcb that fits under all the button pads, but that’s a lot more than I was planning on. JLPCB and elecrow will make pcbs that big for ~$10 each, but it’s a tedious button pad design. Could do a smaller PCB, only do some of the buttons, just for less hassle, but, meh. Could try and probe up some buttons, lay a big rats nest of wire down. Possibly the easiest way would be to desolder one of the ICs and put something in it’s place, a bunch of selective trace cutting, see if all the buttons go there? Or maybe just look for a different phone altogether…

Cypress CY8CKIT-049-42XX – PSoC 4200 kit – first impressions

(This was a draft I write in 2015, thought I might as well publish it where I’d left it)
Cool packaging, just like in the PSoC5LP kit. Despite looking similar, with a breakoff section that plugs into USB, the “programmer” side actually isn’t. It’s Cypress’s USB Serial bridge chip, the CY7C65211, and you program by using the UART bootloader on the PSoC 4200 target. Totally functional, totally valid. Not nearly as useful as a full debugger for application development of course, but in effect, it’s a full eval board for the usb serial chip. You can get a config tool that turns it into USB-SPI, USB-I2C, and USB-GPIO dongles. Neat, but still, I didn’t get this to evaluate usb serial bridge chips. On the bright side, it does at least detect properly out of the box as a serial UART in linux. (Unlike the KitProg on the PSoC5LP kit)

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.