Seek CompactXR

[ddcc]

I recently picked up a Seek CompactXR for iPhone that doesn't show up over USB. Since I don't have an Apple device, I ended up soldering a USB cable directly onto the board, which has the 5-pin USB OTG pads, instead of messing with the lightning connector.

In the below photo, on the left is a TI TPS62560 buck converter, in the middle (from top to bottom) is an Apple 337S3959 authentication coprocessor and a STMicroelectronics ECMF02-4CMX8 common-mode filter/EFI protection for USB, and on the right is a NXP LPC43S30FET100 dual Cortex-M4/M0 ARM processor. Not pictured is a Spansion S25FL032P 32Mbit flash memory on the back.



Starting with the converter, it reduces the 5V input down to ~2.3V, which is within the operating parameters for the NXP processor, so it's not a power problem. Since the D+/D- lines for USB run through the STMicro filter/choke, I desoldered it and bridged its pins in order to rule out this part.



But, the USB interface still doesn't appear, so the fault appears to lie within the NXP processor. I'm guessing that this must be fairly early in the boot process, since the built-in USB controller doesn't seem configured, though I haven't checked since the USB interface is too fast for me to examine with my scope. The processor is definitely starting though, because the oscillator is working, and the Spansion flash memory is being read. I was hoping for an unpopulated debug UART, but I haven't found one so far, and the ten pads to the bottom left of the processor appear to be JTAG.

At this point, my options seem pretty limited. I haven't worked with any NXP processors before, but I'm guessing that even if I figure out the JTAG pinout for those ten pads and connect a Segger probe, the debug interface may be disabled, or I'll encounter some sort of code protection. Another possibility could be that the actual fault is with the Spansion flash, though I haven't dumped it and I don't know what it's storing. Any suggestions?

[ddcc]

I ended up buying a second unit (for Android) with a broken microUSB port, but otherwise still functional. After dumping the flash and comparing them, there was no obvious data corruption, as most of the differences were obvious; e.g. calibration data, various metadata (last use, serial number, etc), while a few others were not, including some code segments. Anyway, since repairing the second unit was much more straightforward, I decided to set this one aside, and focus on that one instead.

It turned out that repairing the microUSB port was more difficult than expected, because it's embedded within an injection-molded plastic assembly. After playing around with it, I realized that building a replacement would be easier, since the shell and pins on the microUSB port are impossible to replace without damaging the whole assembly. Additionally, since my phone has USB type-C, it would be more useful to use that connector instead of microUSB. Plus, it seems Seek themselves don't even sell a type-C version.

Long story short, this gave me an excuse to learn and play with 3D printing, which involved modeling up the replacement part in CAD software, and printing it out in plastic. This took a few attempts due to issues with model accuracy, printing resolution, tolerance, minimum wall thickness, support material, etc. In the end, I used Shapeways for the final print. Additionally, I also had to build a small interface PCB to mount the type-C connector, and handle the USB type-C signaling requirements on pin CC1 for operating in USB 2.0 mode. This also took a few iterations, due to changes in the board layout (to fit it in the printed plastic assembly), OSHPark's fab accidentally using 1.6mm FR4 instead of 0.8mm FR4 for the straddle-mount type-C connector, incorrect signaling on pin CC2, etc.

type-C on the left, broken microUSB on the right.


board v1.0 with the printed plastic assembly on the left. it folds to the right in order to fit on top of the Seek PCB. optional FFC connector, if the Seek microUSB FPC is unavailable.