The booby-trapped DevTerm GPIO

NOTE: my experience is with the R-01 module, but since the mainboard remains the same regardless, this will apply to all available brains.

I wanted to add an RTC to my DevTerm. This is something that has been quite simple on my other SBC based devices. I knew it would be a challenge with this one because of the unconventional connector employed. I went to Adafruti looking for a suitable break out kit but didn’t find what I wanted. So I went over to new egg and found the parts: break out PCBs, the .5mm pitch 40pin SMD socket to solder to the boards and two varieties of appropriate FPC ribbon. I eagerly waited their arrival and surfed YouTube for hints on how-on-earth I was going to hand solder these! Much to my amazement I managed to get it right and only had to throw away one board! I ohmed out my board and it didn’t have any cross shorts and all pins conducted from cable to PCB! :joy:

I’ve been really pushing my SMD hand soldering skills this past month.

Misattaching my DS3231 module to the breakout board caused the WiFi module to disappear! :astonished: This got me scrutinizing the schematics in greater detail. The way modern schematics use labels to connect things tends to hide what would otherwise be obvious connections. Chasing labels around I found that most of the GPIO on the 40 pin GPIO connector is already used by the WiFi module on the mainboard! :scream: :bomb: :bomb: :bomb: The major “booby-trap”.

I suppose desoldering it is an option… yeah right.

EDIT: When all is said and done there are only 9 pins left (besides power): See @yatli’s chart below. There is nothing left. :bomb:

What the GPIO pins actually get you is going to be dependent on the compute module and will have to be traced down on the individual schematics since ClockWork doesn’t provide any data, that I’ve found, which is another “booby-trap”. :bomb:

EDIT: NOTE: Since the mainboard has a use for all these signals all compute modules will need to provide the same signals or you end up losing features. But where they connect on the SOC is still up to investigation.

So when I read “40pin GPIO connector” on the site, I was thinking that this was like a Raspberry Pi with 40 pins worth of signals I could actually use. Its almost like false advertising to find that they have already used most all of them and should of just provided “12 pins of GPIO”. They might have even been able to use a connector more suited to humans.

But this isn’t where the booby-traps end. While testing my wiring I thought I’d twiddle a GPIO pin and check it with a volt meter to see that it was actually showing up on the pin I thought it should. In my particular R-01 case I started with Allwinner pin PE1, which is supposed to be GPIO11 and pin 23 on the connector. Much to my surprise the kernel griped the pin was already in use. :bomb: I can’t tell from the schematics why that is or where it is. This is likely going to take spelunking through device trees and kernel source… I don’t know if other SOMs would have this issue. But it seems QC is missing.

When I attached my DS3231 to what the schematics call TWI0 the system will not boot. It just sits on a black screen. :bomb: This was a working module from another project. So I’m not sure what to make of this and once again the schematics don’t show anything amiss… unless I missed a label somewhere. I’m guessing this has something to do with the R-01 kernel.

EDIT: as is shown in the chart below I am stepping on the PMU I2C interface. My DS3231 has address 68H and so does the AXP228. I assumed the power section of the mainboard schematic didn’t need to be looked at. :frowning:

The good news: if you make something to plug into PCIe connector all of those pins are available. And who knows… they may actually be supported! :joy:

So for those thinking they can use that GPIO connector for something beware! There are lots of booby-traps ahead and it most likely won’t work. They should have just left the part off the board and saved the cost.


I’ve just made this, a map for the nonfree connector.
This is more like a man in the middle debugging port that you can hook up to see what’s going on, because there are effectively 0 free pins.


Thanks for that sleuthing. Very annoying. :angry: I talked to Clockwork specifically about adding an I2C RTC before I bought the DevTerm and they never stated the GPIO connector was already used. Yes, I would call it a “debug” port too.


Since the I2C bus can be shared with multiple devices its still possible to use it on the GPIO connector… in theory. You just have to make sure your devices are on different addresses. The AXP228 (PMU), which is on the bus is using addresses 68H and 69H. Unfortunately for me the DS3231 is using 68H also. And this explains why the DevTerm can’t power on with my RTC installed. :bomb: ::sigh::

Thank you @yatli for your effort and chart.

1 Like

Here’s the table itself. The forum does not allow uploading this.
We need a wiki.

@ChipMaster maybe connect that to EXT module? Use some spare GPIOs to do software i2c. Edit: there is a free i2c on EXT.

There is a wiki, if you hover over “Community” on the main page

I made another table that maps EXT pins to the core modules:

  • R01 is a peripheral beast.
  • CM3 has the best HAT compatibility.
  • A06 least flexible but fine
  • A04 ??? still no schematic
  • CM4 ??? no adapter board schematic
1 Like

Yeah, not useful or applicable. The GPIO documentation that you would find on some place like Raspberry Pi’s site is completely missing and what is there seems to be aimed at the game shell.

To do it right you’d need to create a map for each compute module so that not only the primary function is documented but also the source pin (ie, where on the SOC it terminates). And to go a step above document all of the possible functions.

But since the GPIO is all used up perhaps you should just document what they tie to on the main board (basically like @yatli has done), on the off chance someone wants to do some debugging. Otherwise there is no point in this connector.

1 Like

Yeah, I had noticed there does appear to be a second I2C bus available on the camera port. I’ll have to check the IDs of all the other peripherals on that module. And then find parts to make a break our for it… It might work. Assuming I’m successful at getting a time source plumbed in I was going to document that in another thread. I wanted to leave this one about documenting the GPIO connector.

Splendid work! Both of these have gone into my documentation folder. I don’t suppose you could provide the source spread sheet in an Open Document file (ods)?

There you go:

Hide nothing :slight_smile:

1 Like

Thank you very much!