The booby-trapped DevTerm GPIO

DevTerm
,
1

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.

4 Likes
2

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.

Screenshot_20230108-161432
Screenshot_20230108-1614321080×2340 420 KB

4 Likes
3

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.

2 Likes
4

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
5

https://nextcloud.yatao.info:10443/s/GxJEHd9tC7qYHNp

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.

6

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

https://wiki.clockworkpi.com/index.php/Main_Page

7

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

image
image2986×828 413 KB

  • 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
3 Likes
8

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.

2 Likes
9

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)?

10

There you go: https://nextcloud.yatao.info:10443/s/osDHaPigK3WxjtM

Hide nothing :slight_smile:

1 Like
11

Thank you very much!

12

Does that apply to CM4? It has a WiFi module on-board, so it shouldn’t need to waste its GPIOs for that, right?
Raspberry Pi 4 Model B somehow manages to have WiFi plus the whole GPIO header, so the Raspi chip definitely can handle it.

13

Hmm… I wonder what fun one could have with dual WiFi… :laughing:

To my knowledge there is only one “main board” for the DevTerm. This means that the mother board WiFi will continue to interact on those lines unless you do something physical (cut traces, …) to stop it.

14

I see. So current DevTerm users who have a CM4 in it, don’t use the integrated WiFi circuit / antenna but the external one, on the mainboard?

15

Not sure, according to the CM4 adapter store page you need to have a CM4 that has wireless itself, so i don’t think you are gonna get your dual WiFi. Maybe they are using these lines for other stuff?

16

I didn’t say that. I said:

That’s all about hardware. I don’t know about the software. I don’t own a CM4 and I don’t know what OS your using or how its configured. So I won’t even make a guess.

The point is that the GPIO lines on the mainboard are taken. That seemed to be your question. I haven’t looked at the schematics for the CM4 adapter (you should) but I can only see a couple of scenarios:

  1. those GPIO lines are being supplied by the CM4, but they are physically attached to the MB WiFi. In which case you physically have two WiFi adapters that you may be able to use.

  2. those lines aren’t being supplied by the CM4, in which case you don’t have them anyways.

The net result: no GPIO. ::sigh::

17

I confess i have not looked at the product. But it doesn’t change the fact that the DevTerm MB still has a WiFi chip on it and its still connected to the GPIO lines that are still connected to the GPIO (debug) header. Plugging different modules into the MB will not change that. Only changing the MB will.

See the two possible scenarios in my reply to @dav3.

Its kind of a bummer if its scenario 2. Not sure what I would do with duial-WiFi but its always nice when there is an unexpected feature you might someday find a use for. :))

18

How about cutting the traces to the MB WiFi and then being able to freely use the GPIO (not just debug anymore) header?

19

That was exactly my idea. I was thinking of kapton tape over the contacts I dont want the motherboard using, then just solder wires to the top part of those pads. Easily reversed, and the adapter board is only like $20 in case I fail.

1 Like
20

Is it possible? Depends on your skills, tools and whether or not the traces are accessible, ie not on an internal layer, under a chip, … Technically if one is skilled and tooled well enough you could probably lift the WiFi chip from the MB…