[SOLVED] Portenta H7 Lite - Low level pin linkage (A5, D8, D9 to A3)

[alvinccli]

Low level pin linkage

I am using a Portenta H7 Lite mounted on a PCB to control some experiment apparatuses.
Issue: Whenever I set the pin mode of any of these pins A5, D8, D9 as OUTPUT, the pin A3 (which is also set as output) would be rendered uncontrollable. Either it will be always HIGH or always LOW.

What I mean is the following blinking sketch would be problematic:

#define pin_LED  A3
#define pin_problem  A5 //A5,D8,D9 any of these pin declared as output would make pin A3 uncontrollable

void setup() {
  pinMode(pin_LED, OUTPUT);
  pinMode(pin_problem, OUTPUT); //comment or uncomment this line to see the difference
}

void loop() {
  digitalWrite(pin_LED, HIGH);
  delay(500);
  digitalWrite(pin_LED, LOW);
  delay(500);
}

Trouble shooting: I initially thought it is the problem of my PCB but it turns out the issue remained when the board is powered by USB and used standalone.
Then I suspect I somehow damaged the board in a previous incorrect connection. However, I ordered a new board and the issue remained. Using Arduino IDE and PlatformIO would both produce the same result.
This is when I started to really suspect there is a low level crosstalk error either software/hardware.
I don't know who to talk to for such low level problem.

If anyone has one of the portenta H7 laying around, please check if your board also suffer from this issue. You only need a LED or multi-meter to probe pin A3.

Board: Portenta H7 Lite (M7 core)

IDE 1: Arduino 1.8.19, Arduino Mbed OS Portenta Boards, by Arduino version 2.8.0
IDE 2: PlatformIO core 6.0.1, framework-arduino-mbed @ 3.0.1, in VS Code

Thank you for your attention.

[hpssjellis]

@facchinm

@alvinccli Great detective work. I tested the PortentaH7 and I get the same results, however not with D9 and when A3 has the problem it never goes HIGH always LOW.

See below what I also found about A2 A4/D10

For me on the PortentaH7 LED on A3, A5 and D8 caused issues D9 did not.
// results PortentaH7
// connected A3 to an LED to a resistor to GND
// comment out pinMode(pin_problem, OUTPUT); LED flashes
// Test A5 LED stays off
// Test D8 LED stays off
// Test D9 no effect A3 LED flashes as per code

// random testing other pins
// A0 is fine
// D21 which is A6 is fine
// A4 is fine

I have for a while been trying to figure out pin issues for the HD connector. Here is a very incomplete csv chart, checkout pin PC_3 it seems to have 2 pins connected to it.

https://github.com/hpssjellis/my-examples-for-the-arduino-portentaH7/blob/master/PINS/shared-best-so-far-csv-portenta-pins.csv#L63

// A2 (PC2_C) should not flash if A4 or D10 (PC_2) is the pin_problem
// For the PortentaH7 same as above A2 does not flash for A4 or D10

I am putting this info in my "Gotchas" area of the "Portenta Pro Community solutions" library here

[pnndra]

Hi,
let me be a bit more precise on terms... there's no crosstalk in Portenta. Crosstalk definition implies that a signal interferes with another due to some electromagnetic coupling whereas the problem here is completely different.
As it can be seen in portenta schematics at HD conenctor page there's a table containing the list of pins that are conneced in two different positions:

in addition to this the _C pins used in A0-A3 are special in the sense that they can be connected via SW to the respective signals without the _C suffix as it can be seen from the diagram in the processor user manual i'm copying below

This means that for pins that are shared really you should use either one or the other function... you can't have them at the same time.
for analog pins the situation is less obvious: if you want to use these as GPIOs then these will be shared with the respective ports (eg. A0 is connected to PA0_C which would coincide with PA0 which is UART4 TX). by default the switch is closed but is automatically opened whenever you issue an analogRead on a _C pin and from that moment on the analog signals will be input only and won't be affected by the respective GPIO.
the issue is that if try to use digitalWrite on A0 (which is PA0_C) that will actually write on PA0, so you have to take extra care when planning resource usage; unfortunately even if STM32H747 has loads of pins we had to make compromises and that's the best we could come up with

[hpssjellis]

@pnndra @alvinccli @sebromero

Can we not close this issue until a working document is created that is easily assessable to the general public and summarizes these VERY important shared pin issues. @pnndra, can you give us links to the 2 above documents? I assume @alvinccli has spent hours on these issues that could have been summarized 2 years ago instead of causing coders enormous amounts of frustration.

Good for you @alvinccli for solving and posting this issue.

With the Portenta things get more complex since PINS can be represented as Ananlog (A6), GPIO (D21) , Names (PA4) or High Density labels. (J2_78). With the new PortentaX8 that also uses the HD connectors I assume this PINS issue is going to get even more complex.

The chart above is not very useful when I am working on my HD connector PCB, or also not useful for a programmer trying to connect A4 and A5 while also using SPI MISO (CIPO) or MOSI (COPI).

It sounds like Arduino Engineers have known about these PINS issues for a while. Arduino has always been good at simplifying coding issues. Could we just make a chart or .csv file of PINS that should not be used together and a little blurb about why.

[alvinccli]

Hello,

@hpssjellis Thanks for confirming my observation. Now I know that it is not just me. Otherwise I would never know.
@pnndra Thanks for your attention to the matter as well.

Maybe I didn't use the proper terminology. I understand the sharing of pins from HD connector and the MKR pinout. (I am only using MKR pins here.) But I have no way to tell that I cannot use A0-A3 as GPIO when some of the other pins are being used.

After all, like @hpssjellis said, I strongly recommend summarizing a list of pins that are incompatible to be used together in general or specific scenario. I read the datasheet multiple times before I make my PCB and I have seen no clues that this could happen. I understand that hardware compromises have to be made but I would appreciate that this information would be available to the user (maybe as a warning) upfront. I imagine that this problem would affect many other users of the Pro lineup.

@pnndra Correct me if I am wrong. Now my understanding is that when using A0-A3 as GPIO (not triggered analogRead):
PA0_C (A0) and PA1_C (A1) are linked respectively to PA0, PA1 (which is on HD connector and I am not using)
PC2_C (A2) and PC3_C (A3) are linked respectively to PC2 and PC3 (which is also A4,A5 respectively, also D10,D8 respectively for SPI1)

Story: In my particular case, I was developing a controller board in my engineering PhD project starting from Jan 2022 and I went through days of frustration thinking I designed my PCB wrong or I damaged the board. I did my due diligence to test individual functionality separately but still didn't know combining totally separate (and seemingly independent) code blocks together would cause failure. What made it worst is that this pin incompatibility issue is (from my perspective) the most hidden place to be found.
Now I have my second iteration of PCB made and soldered but the main functionality of the board still rely on A0-A3 pins as GPIO. So instead of committing to make another iteration of the board and go through all the trouble, I might have to switch to MKR Zero instead. The MKR Zero seems to have the MCU pins all separate.

TLDR: Please, please make it more explicit as of what pins cannot be used at the same time. It is crucial information and would be extremely helpful to all users of the H7/X8.

Thanks a lot!

[akash73]

thanks @alvinccli @hpssjellis for pointing this out. we'll add the relevant information to the datasheet!

[pnndra]

Can we not close this issue until a working document is created that is easily assessable to the general public and summarizes these VERY important shared pin issues.

This repo is not the right one to report issues with documentation. if you want anything to be changed/added to documentation we have the public docs repository which contains source for all docs.arduino.cc and, among other things, include the Portenta datasheet. you can suggest modifications to any document via a pull request or open an issue there

@pnndra, can you give us links to the 2 above documents? I assume @alvinccli has spent hours on these issues that could have been summarized 2 years ago instead of causing coders enormous amounts of frustration.

sure. the schematics are here (see last page for HD connector pin assignments and notes) while the STM32H747XI reference manual is here and you can find that block diagram at page 577, figure 82 of the current (rev 3) document.

With the Portenta things get more complex since PINS can be represented as Ananlog (A6), GPIO (D21) , Names (PA4) or High Density labels. (J2_78). With the new PortentaX8 that also uses the HD connectors I assume this PINS issue is going to get even more complex.

yes, it's true that these products are way more complex than the old arduino products. believe me we've tried to pack as much information as possible in the most readable way but it's always difficult to find the right tradeoff between summarizing what's needed in most use cases and adding all the details (there are really many for these boards).

The chart above is not very useful when I am working on my HD connector PCB, or also not useful for a programmer trying to connect A4 and A5 while also using SPI MISO (CIPO) or MOSI (COPI).

It sounds like Arduino Engineers have known about these PINS issues for a while. Arduino has always been good at simplifying coding issues. Could we just make a chart or .csv file of PINS that should not be used together and a little blurb about why.

as @akash73 wrote we're going to write something about this. unfortunately things are more complex than they seem... as i wrote it's not just about pins that can't be used together like the ones in the table i pasted but also the _C pins that can be used separately when they're used as analog (their main function) but not if you use them as GPIOs. any suggestion on how to make this readable and readily understandable is very welcome but keep in mind that for example not many people open the full pinout file which may hint at some of this information

@pnndra Correct me if I am wrong. Now my understanding is that when using A0-A3 as GPIO (not triggered analogRead):
PA0_C (A0) and PA1_C (A1) are linked respectively to PA0, PA1 (which is on HD connector and I am not using)
PC2_C (A2) and PC3_C (A3) are linked respectively to PC2 and PC3 (which is also A4,A5 respectively, also D10,D8 respectively for SPI1)

@alvinccli you're right in everything except that PA1 is on HS USB PHY interrupt pin; this may be a problem for you.