• RPi CM4 and Radxa CM3 versions of the board

    Evan • 01/26/2022 at 07:53 • 2 comments

    Since the last time I had a board made, I've discovered several revisions that I needed to make:

    - The 5V boost of the bq25895 cuts out long enough to shut off the Pi when you connect USB power.

    - I needed extra lanes of DSI going from the CM4 to the SN65DSI83 chip in order for all the clock rates to fall within the ranges allowed by the SN65 and the iPad's display.

    - The footprints for my touchscreen FFCs were backwards

    I took this opportunity to design a version of the board where I actually used the CM4 instead of having separate 40-pin connector / FFC for DSI / USB port on the board. I threw an M.2 slot on there for NVMe support, as well.

    The CM4-based version of my board.

    When I was nearly finished with that design, I learned about the Radxa CM3, which is the same form factor as the Raspberry Pi CM4 but has a third board-to-board connector providing several features that would be quite convenient for this application:

    • Audio codec with headphone out, mono speaker out, and microphone in
    • Battery charger
    • Power button handling
    • Native LVDS support on the DSI0 pins (and the extra DSI0 pins are broken out)
    • HDMI pins can also output DisplayPort (the dock connector on the iPad can speak DisplayPort, which is used to drive the 30-pin to HDMI adapter.)

    In addition, the Rockchip RK3566 that the Radxa CM3 is built around actually seems to have the ability to sleep, which is especially important on a tablet. On the CM4, I'll have to suspend to disk or just shut down or something.

    I think if I the Radxa CM3 had existed when I started this project, I might've chosen it over the Pi CM4, as it should require a lot less glue circuitry to make it work in this application. (I had originally considered the Pine64 SOPine and the Nvidia Jetson Nano, but I think I excluded these because the SO-DIMM connectors that they require wouldn't fit between the case and the screen.) As a bonus, the RK3566 is less tall than the BCM2711, which may buy me a little vertical room, depending on the other components on the CM3.

    I've also designed a version of my board based around the Radxa CM3. Once I figured out the position and orientation of the third connector on the CM3, this wasn't too bad -- it has far fewer components than the CM4 version of the board. It's essentially just connectors, the touchscreen controller, a buck-boost converter for the NVMe slot, and some audio switches.

    Radxa CM3-based version of my board

    Since the Radxa CM3 / RK3566 clearly has less software support than the Pi (I think as of the time of writing, you can't even get HDMI output, let alone LVDS.), I'm planning to hedge my bets and have both boards made.

  • Colors! (sn65dsi83 test pattern)

    Evan • 08/23/2021 at 06:26 • 0 comments

    Thanks to the help of some folks on the Raspberry Pi forums, I've got the sn65dsi83 driver loading, and the Pi generating enough DSI signal for the SN65DSI83 to be able to generate a test pattern (it uses the DSI clock to generate the LVDS clock)

    Hopefully I can get those black lines to go away.

  • Using ftrace to debug device tree problems

    Evan • 08/18/2021 at 07:28 • 0 comments

    For the past few days, I've been trying to get the sn65ds83 driver (recently added to linux) running and talking to my board. It has been a (re-)learning experience trying to get this device tree overlay to cooperate.

    Following my own advice from the last time I touched device trees, I used udevadm monitor and dmesg -w to watch for kernel/udev messages while loading my overlay with sudo dtoverlay pipad_screen. This gave me this helpful error message:

    [  178.309859] sn65dsi83: probe of 1-002d failed with error -2

    From what I can tell from looking at the kernel source, this implies that the sn65dsi83_probe function was returning -2. Unfortunately, the sn65dsi83_probe function can return errors from several different places. Fortunately, there's a kernel feature called ftrace that can trace every function call that happens within the kernel. The easiest way to use it is to use the trace-cmd command, which you can install on Raspberry Pi OS with apt install trace-cmd. You record with trace-cmd record -p function_graph (with various options for filtering), then view the results with trace-cmd report.

    Supposedly, you can trace everything by just running trace-cmd record -p function_graph with no filter options, but when I tried this, I had a lot of dropped events and didn't see the sn65dsi83_probe function in the results.

    After learning some things about ftrace (by manually constructing a list of functions to filter on with the -l flag), I discovered that ftrace can only trace functions in kernel modules that are loaded before ftrace starts. Normally, the ti-sn65dsi83 module is loaded automatically when I run dtoverlay pipad_screen, but that prevents ftrace from seeing it.

    If I manually modprobe ti-sn65dsi83 before running trace-cmd record -p function_graph -F dtoverlay pipad_screen, I get no dropped events, and the trace for the sn65dsi83_probe function was there in the output of trace-cmd report:

    sn65dsi83_probe() {
  devm_kmalloc() {
    __kmalloc_track_caller() {
      kmalloc_slab();
      should_failslab();
    }
    devres_add() {
      _raw_spin_lock_irqsave() {
        preempt_count_add();
      }
      _raw_spin_unlock_irqrestore() {
        preempt_count_sub();
      }
    }
  }
  of_device_get_match_data() {
    of_match_node() {
      _raw_spin_lock_irqsave() {
        preempt_count_add();
      }
      __of_match_node.part.0() {
        __of_device_is_compatible() {
          __of_find_property();
          of_prop_next_string();
        }
        __of_device_is_compatible() {
          __of_find_property();
          of_prop_next_string();
          of_prop_next_string();
        }
      }
      _raw_spin_unlock_irqrestore() {
        preempt_count_sub();
      }
    }
  }
  devm_gpiod_get() {
    ...
  }
}

    This implies that sn65dsi83_probe was returning immediately after the call to devm_gpiod_get finished. Oh, right, I never put the enable GPIO pin for the sn65dsi83 in my dts file. I figured the property would be called enable because that's the string being passed to devm_gpiod_get, but nope. From looking at documentation for other bridges, I inferred that it's enable-gpios.

    Adding enable-gpios = <&gpio 5 0>; to my device tree and trying again, this time I get from dmesg -w:

    [   95.093834] sn65dsi83: probe of 1-002d failed with error -22

     Looking at my report, this time I see:

    sn65dsi83_probe() {
  devm_kmalloc() {
    ...
  }
  of_device_get_match_data() {
    ...
  }
  devm_gpiod_get() {
    ...
  }
  of_graph_get_endpoint_by_regs() {
    ...
  }
  of_property_count_elems_of_size() {
    ...
  }
  of_graph_get_remote_port_parent() {
    ...
  }
  of_node_put();
}

    Looks like it's failing just after of_graph_get_remote_port_parent and of_node_put. These aren't called directly from sn65dsi83_probe, but by sn65dsi83_parse_dt. Because sn65dsi83_parse_dt is defined as a static function, it can't be traced by ftrace, and everything it calls appears directly beneath sn65dsi83_probe.

    I think I'm being caught by this code:

        ctx->dsi_lanes = of_property_count_u32_elems(endpoint, "data-lanes");
    ctx->host_node = of_graph_get_remote_port_parent(endpoint);
    of_node_put(endpoint);

    if (ctx->dsi_lanes...
    Read more »

  • First light: testing and fixing the backlight controller

    Evan • 07/10/2021 at 05:07 • 0 comments

    Based on my guess of how complicated testing the different components will be, I decided to test the LCD backlight controller next. 

    For this part of my PCB, I basically built the example circuit from the datasheet of the TPS61176. This chip is essentially a DC-DC boost converter and 6 constant-current/PWM sinks. You control it by providing a PWM signal on its PWM/EN input. It decodes this signal and then runs its own PWM on each IFB# pin.

    Not wanting to risk frying my iPad's display, I wanted to first test with my own string of LEDs. However, I'm a dummy and I neglected to put any test points on this part of my PCB, and because both ends of the trace end up at fine-pitch footprints, I opted to scrape away some solder mask and solder some magnet wire directly to some traces.

    Magnet wire soldered directly to traces. Don't forget to add test points to your PCB!

    I dead-bug soldered a few LEDs together to make my test string, and connected them to the common anode and one of the cathode lines, which works great:

    fading the brightness from 0% to 100%

    The TPS61176 will increase the anode voltage until your LEDs start actually drawing current, so it basically supports strings of LEDs with arbitrary forward voltage, within its voltage range.

    After double-checking that I hadn't flipped the pinout for the display, I decided to connect the actual LCD panel. Powered it up and ....nothing. Black. The anode voltage was 3.6V (so, not boosted at all). My hypothesis is that it's detecting an open circuit on all the LED strings, so it disabled the boost converter. Some basic testing confirms:

    The anode voltage jumps (higher than my Saleae Logic 8 can measure), and then falls back down. I wonder how high that voltage is going? Is it higher than the 18V required to drive the backlight on the LTN097XL01-A01 panel in my iPad?

    I soldered a few more wires onto my board: one at the MODE/FAULT pin, and one at the OVP pin (which is connected to a voltage divider with 143k / 1M, which divides the anode voltage by 8). Rerunning the test gives me:

    1.5V at the OVP pin. There's my problem! Turns out the reference voltage for the OVP pin is 1.5V, and with the 1/8 division, I'm only getting 12V max. I need to adjust the ratio on my voltage divider.

    After swapping the 143k resistor for an 82k resistor, the backlight works! 

    the backlight on my LTN097XL01-A01 glowing

  • Power supply testing, part 2

    Evan • 07/08/2021 at 06:05 • 1 comment

    I assembled the front of my board yesterday (dealing with 0402 components is tedious. I really should just pay JLCPCB to solder on most of the passives for me.) Today, I wanted to quickly test the power supply to make sure I hadn't broken anything yesterday.

    I attached a battery (I managed to find another LiPo battery buried in a drawer), checked output voltage (5.1V ☑️), wired up the raspberry pi (which booted.) Everything seems to work as well as it did two days ago. However, I tested a few things that I hadn't tested before, and discovered a few unfortunate things:

    When I plugged in the USB charge cable, the red LED on the Raspberry Pi shut off. However, the Pi didn't actually shut down - I think the input voltage dropped just enough that the Pi turned off the LED. (The USB charger I'm testing with only puts out about 4.5V.)

    However, when I unplugged the USB cable, the Pi did actually shut off. Turns out, it takes about 38ms for the bq25895 to start the boost converter after VBUS drops to 0, so my 5V output drops to about 0.2V below Vbat, so about 3.6V in this case. (probably being fed entirely through the external Schottky diode.)

    Screenshot of Logic 2 showing the voltage drop on the 5V output when you unplug the USB input cable.

    From this trace of the various voltage rails, we can see that PMID (the 5v output of the bq25895) and 5V @ pi (the pi's 5v rail, connected by wire to PMID - I just wanted to make sure there wasn't too much voltage drop on the wire) drop down to about 3.6V. This is low enough that the Pi shuts down its 3.3V rail.

    Because of this issue and the risk of USB voltage being passed directly to the Pi if the bq25895 negotiates a higher voltage, I think I'm going to have to add a separate boost converter like the SuperPower-RPi project does. (I based my bq25895 schematic heavily off of theirs.)

    Thanks a ton to Seth K from the SuperPower discord for his input on this.

  • Power supply testing

    Evan • 07/06/2021 at 06:31 • 0 comments

    So I finally finished designing v0.0.1 of my PCB, and had them made by JLCPCB.  This prototype has:

    • touchscreen controller
    • MIPI-DSI to LVDS converter
    • LED backlight driver
    • battery controller/boost converter
    • audio codec, speaker amplifiers, and footprints for speaker and headphone connectors
    • connectors for the 30-pin dock board and the ambient light sensor
    testing the fit of my v0.0.1 prototype board inside the iPad.

    Instead of having the two 100-pin connectors for the CM4 like the final board will have, this version of the PCB is designed sort of like a Pi HAT, with a 40-pin header on the bottom. It also receives the video signal through a 15-pin ribbon cable, and has an extra USB micro B connector wired to the battery controller. This design allows for safer testing: I can connect only the pins that are needed to test one feature at a time.

    I've assembled only the bottom of the board so far (the battery controller and the DSI-to-LVDS converter), and have been working on testing the battery controller.

    My battery controller is adapted from Pi-Charger.sch from the SuperPower-RPi project, which is essentially the example schematic for the bq25895 battery controller from TI. In the SuperPower board, they use a separate boost converter to go from battery voltage up to 5V, but on my board I decided to use the bq25895's built-in boost converter, which can provide 3.1A at 5V if you add an extra diode. This approach has risks, and I will revisit this decision.

    First thing I did to test it was give it 3.6V on the battery+ and ground connectors, hoping to see 5 volts output, but no dice. After scanning through the i2c registers, I eventually noticed that it was complaining about the thermistor being missing. After adding a 10k resistor... still no dice. Turns out I needed to pull the OTG pin high. Good thing I broke that out to a test pad!

    I futzed around for a while with various approximations of the iPad's battery (3x NiMH AA's in series; some old, fairly degraded 18650s out of a battery pack from a broken bike light). These all had too much internal resistance to supply the ~15 watt spikes required to boot the RPi 4, and would trigger the bq25895's undervoltage shutoff. Eventually, I gained enough confidence in the board to test with the iPad's actual battery. This worked great!

    Prototype board connected to the iPad's battery, powering a Raspberry Pi 4

    It seems like the iPad battery is in pretty good condition - at least, it's been holding a charge, and still has very low internal resistance. I measured maybe 50mV of voltage droop when booting the Pi 4.

    Up next is probably testing the LED backlight driver, then after that I can test the LVDS controller. I may or may not be able to test the touchscreen controller: the FFC connectors are backwards. 🤦♂️

  • Attempting to write a device tree overlay for the soundcard

    Evan • 03/22/2021 at 03:54 • 0 comments

    Since my last log, I connected the other ends of the magnet wires to female header pins so that I can attach to my RPi 4. I really, really would recommend against trying to do it this way. I'm either gonna spend the board space and use 0.1" headers next time, or go for something easy to solder like an FFC so I can make a matching breakout board.

    In the mean time, I've tested the board a bit, and have been working on making it work under Linux.

    For basic testing, I used command line tools for I2C (i2cdetect, i2cset, i2cget from the i2c-tools package. From this, I was able to confirm that the codec powers up successfully, I can speak to it over i2c, and that jack detection works. (This codec can tell the difference between a TRS stereo headset and a TRRS stereo/mic headset, based on the resistance between the different pins.)

    I still have no idea whether I can actually make sounds with this thing, though. To get sound, I need to:

    1. Toggle GPIO pins to enable the dual LDO and the codec
    2. Configure the codec via i2c so that it knows which of its several output pins to use, and what format we'll be sending on its PCM/I2S pins.
    3. Actually send I2S to it.

    I could probably script all that, using python or bash or something, but since in the end I want to make this work as a fully-supported alsa/pulseaudio/whatever output, I started learning how to do this Properly™. The basic approach is to make sure the kernel has a module available for the codec, then write a "device tree overlay" describing the board.

    The Linux kernel source already have a driver for the TLV320AIC3104, but they aren't included by default in Raspberry Pi OS. After cloning, configuring to enable the tlv320aic3x driver, and rebuilding the kernel, I have the snd_soc_tlv320aic3x module available.

    Next, I need a device tree overlay for my board. This will tell the kernel what hardware I've attached to the computer, and if all goes well, the kernel should load and instantiate the appropriate drivers.

    The Raspberry Pi website has a decent page about device trees, overlays, and parameters. The kernel documentation also has some useful pages about it: Linux and the Device Tree. It's also helpful to  I cargo-culted my first version of my overlay, compiled it, put it in /boot/overlays, added it to config.txt, and rebooted, and... how do I know if it worked? After playing around and searching for things, I was able to find a couple useful debugging tips:

    1. Check dmesg for anything obvious. 
    2. On Raspberry Pi devices only, you can get bootloader logs with 
      sudo vcdbg log msg
    3. This forum post recommends booting without the overlay enabled, then load the overlay at runtime with the dtoverlay command while running udevadm monitor. I've found it's also helpful to be running `dmesg -w` also. 
      # in one terminal:
dmesg -w
# in a second terminal:
sudo udevadm monitor
# in a third terminal:
sudo dtoverlay pipad

      You'll find devicetree-related messages in dmesg often have the prefix "OF:", which I think refers to OpenFirmware, where the device tree concept was originally created.

      Unfortunately, this doesn't shorten the iteration cycle -- every time your overlay fails to properly apply, you need to reboot to get back to a clean state. (It looks like you should be able to remove an overlay with dtoverlay -r, but this doesn't work if your overlay doesn't apply cleanly.)

    After iterations, I've settled on this .dts file:

    /dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2835";
    fragment@0 {
        target = <&gpio>;
        __overlay__ {
            aic3104_reset: aic3104_reset {
                brcm,pins = <17 27>;
                brcm,function = <1 1>;
                brcm,pull = <1 1>;
            };
        };
    };

    fragment@1 {
        target-path = "/";
        __overlay__ {

            vcc30: fixedregulator@1 {
                compatible = "regulator-fixed";
                regulator-name = "fixed-supply";
                regulator-min-microvolt = <3000000>;
                regulator-max-microvolt = <3000000>;
                gpio = <&gpio 22 1>;
 startup-delay-us = <70000>;
...
    Read more »

  • Finally, things to solder!

    Evan • 03/09/2021 at 08:01 • 0 comments

    My most recent JLCPCB order arrived today, which contained:

    I also included a stencil for the soundcard.

    I soldered the breakout board for the AXK770147G with the drag soldering technique, which I definitely need to practice. I needed to do a lot of cleanup with solder wick, plus I seem to have destroyed some of the solder mask. After some basic continuity checking, everything seems okay (though now that I'm looking again, it seems like I may have a bridge between two pins on the bottom right.

    Unfortunately, it seems like I designed it upside-down. (It still pretty much works as a breakout, but I had intended for the double row of header pins to be on the top, not the bottom. Double check the orientation of critical connectors before routing! This isn't a big deal for this board (I mostly ordered this as a way to test continuity to pins on the 30-pin dock connector, and this board still works for that purpose, even if several of the pins are only accessible from the back.)

    I also soldered the I2S board. (It's an odd shape because it's supposed to wrap around the touchscreen controller board.)

    This went pretty smoothly, all things considered! This was my first time working with solder paste, stencils, and hot air. With the stencil ensuring that I had a reasonable amount of paste on each pad, I found the paste very forgiving. Squeegee some paste through the stencil, use tweezers to carefully place each part (nudging as necessary), and then gradually heat with the hot air station. Repeat for the back.

    I caught a mistake with this I2S board pretty soon after I submitted the JLCPCB order -- I had laid it out with 0402 footprints for the 220uF capacitors, which you cannot get in such a small footprint. I've updated my board layout for 1206 footprints. I may end up adjusting the board so I can have JLCPCB assemble most of it for me -- put all the passives on one side, so I'm only doing the larger ICs. Before I reorder this board, I want to test it. In the mean time, I ordered the highest-capacity 0402 caps you can get on Digikey (22uF). This will mean I have terrible bass response, but I should still be able to test basic functionality.

    (I'm tempted to redo this board with a codec with ground-centered "capless" headphone outputs. These ICs provide their own negative voltage rail with a charge pump, and can drive the headphone output to negative voltages. This avoids the need for bypass capacitors, and provides even better bass.)

    For some reason, I had decided to use 1mm-pitch header holes on this board. I guess I was hoping if I got the board right, I could leave it as is and use small wires to connect to other boards.

    Most forms of hookup wire I have on hand have insulation that is larger than 1mm diameter, so I ended up going with enameled magnet wire. Magnet wire takes forever to strip.

    I think in the future, for small-pitch headers, I might go for 1.27mm. The standard rainbow "Dupont" jumper wires that you can find for cheap with 0.1" male or female pins on either end seem to be 1.27mm-pitch ribbon cable, so it would be much easier to solder some ribbon cables in place. Either way, if I do header pins this small again, I'll buy actual header pins and get a breakout board to 2.54mm headers manufactured. Maybe I should just buy some generic FFCs and breakout boards?

    Looks like the connectors are in the right place / orientation, at least!

    Still to do on the soundcard:

    1. Solder the other end of those magnet wires to some female header pins that can mate with the RPi 4 / CM4IO's 40-pin connector + something that can provide power.
    2. Test out the board.

  • Video output research

    Evan • 03/02/2021 at 07:14 • 0 comments

    While I wait for my audio board and breakout boards to show up, I started working on the video output side of things.

    The Raspberry Pi CM4 has four ways to output video:

    • 2x HDMI
    • 2x MIPI DSI
    • 1x DPI
    • 1x Composite

    I need to convert these into three different formats (in order of priority):

    1. LVDS (FPD-Link or OLDI maybe) for the LP097X02-SLA1 built-in display.
    2. DisplayPort for powering 30-pin video dongles such as the Digital AV Adapter (HDMI) or the 30-pin to VGA Adapter.
    3. Composite and/or S-Video for the 30-pin connector

    I'm not sure why Apple went with DisplayPort internally. I guess Macbook Pros of that era already had Mini DisplayPort ports. HDMI is roughly as complicated as DisplayPort, though, and would have simplified their HDMI dongle without adding much complication to their VGA dongle, in my opinion.

    Here are the various options for converter ICs I found:


    		DisplayPortLVDS
    HDMI x2STDP2600 (0.8mm BGA - doable?)TFP401 (HTQFP) -> SN65LVDS93 (TSSOP)
    ADV7613 (0.8mm BGA)
    RTD2668 (massive QFP)
    MIPI DSI x2SN65DSI86 (tiny BGA)
    SN65DSI86-Q1 (HTQFP)
    PS8640 (tiny BGA)
    TC358766X (tiny BGA)
    ANX7805 (tiny BGA)
    		SN65DSI83 (tiny BGA)
    SN65DSI83-Q1 (HTQFP)
    DPI x1 (Parallel RGB)ANX9807 (0.8mm BGA)
    STDP4028 (0.8mm BGA)    		SN65LVDS93 (TSSOP)

    I think the SN65DSI86-Q1 and SN65DSI83-Q1 are my best bets:

    • For some reason, MIPI seems like a simpler on-board video format than HDMI.
    • TI didn't have any single-chip solutions for HDMI -> DP or HDMI -> LVDS, and going with another manufacturer would ruin the TI hegemony I've found on my boards. (But actually, TI has pretty good datasheets and training videos and will sell you things in small quantities.)
    • QFP packages are pretty small, but will avoid the difficulties of tiny BGA packages.
    • DPI would use up a lot of the GPIO pins.

    It's not nearly done yet, but I've started making progress on the board for both LVDS and DisplayPort (as of right now, I've mostly wired up the SN65DSI83-Q1 but haven't finished the LED backlight driver nor started on the DisplayPort side of things.)

  • A more reasonable touchscreen controller IC

    Evan • 02/25/2021 at 08:06 • 0 comments

    In my first project log, I had designed a PCB for interfacing with the touchscreen digitizer, based around Atmel's mXT2952, which was the only device I managed to find that had:

    • datasheets available
    • enough drive / sense pins for the iPad's screen (40 drive, 30 sense)
    • a reasonable minimum order quantity

    Unfortunately, the mXT2952 is a tiny 5mm x 10mm 162-pin BGA, with 0.5mm pitch. This is a tiny, tiny package, and they made it extremely dense -- many BGA chips have a few rows of pins, some blank spaces, then a few more rows of pins. To fit a trace between two pads, you need 3 mil traces and 3 or 3.5-mil spaces. To fit a via between four pads, you need vias that are less than 0.25mm diameter / 0.15mm drill. While there are some PCB manufacturers online that claim to have these specs, the cheapest I was able to find was about $150 according to their online quote form (others seemed to be $300 and up). When I engaged with the cheap one, they told me they couldn't actually do 0.15mm drill holes.

    So I sat on this problem for a while, thinking maybe I'd eventually bite the bullet and spend several hundred dollars on a more expensive manufacturer.

    The other night, I searched the web again for "capacitive touchscreen IC", and saw some results for the Goodix GT911 and GT9271. The latter is used in the Pinetab, and it's one of the first touchscreen controllers I considered. However, the GT9271 only has 32 drive / 20 sense pins - not enough for the iPad's touchscreen, and the GT911 has even fewer.

    Long ago, I had tried looking on the Goodix webpage about their touchscreen controllers, which indicates that they have controllers that should work for even larger displays. This page has zero links or product numbers on it, however.

    I searched around to see if I could find a full listing of all the ICs in the gt9xx family, and searched for every part number I found. Eventually I stumbled on the GT9110 and GT9113 (which seem to be nearly pin-compatible). Both of these have datasheets available online (not from goodix.com, of course), were available for purchase on AliExpress, and have a reasonable 0.4mm-pitch 88-pin QFN package.

    I've created a new PCB design based around the GT9113 (should work for the GT9110 also - some of the broken-out pins become NC on the 9110).

    As always, if you have any feedback, please let me know!