Zero pin usage

Please help me out and teach me something.

I have a custom Zero board which has been working fine for its intended use. Recently I had an idea that involved using some of the available pins that had not been used before. As part of this I needed to use four pins for an LCD test display.

The available pins were SAMD pins 38, 39, 29, 37 as LCD D4, D5, D6 and D7. These pins translate to Zero pins 31, 26, 6 and 30.

I got Japanese characters on the display. Looking at the four pin outputs on a scope I could see that pin 37, D7, Zero pin 30, was stuck high.

I used another PCB, same result.

Pins 30 and 31 are in the same variant group. All of the pins I chose are listed in the documentation as available Zero pins but, of course, not on the connectors of the Zero board.

Testing shows the pin is high at the SAMD and I have checked the wiring carefully so I do not think this is a wiring fault.

I have to be missing something here. Pins 30 and 31 seem to be identical in the Zero variant so I am surprised they do not work the same way. Any ideas?

Thanks, Brian

On the Zero, Arduino pins 30 and 31 are Serial, connected to the EDBG chip.

Thanks Pert,

On our custom board pins 37, 38, 39 are connected as outputs through a voltage converter.

I have thought of some more tests I can perform tomorrow to pin (accidental pun) down the problem.


When referring to pins, I recommend either using Arduino pin number or the port/bit notation (e.g., PB22). Since they differ from one IC package to another, physical pin numbers are really only relevant when talking about hardware design.

Even if your board doesn't have an EDBG chip, if you're using it as a Zero, those pins are being manipulated in software in a manner which might cause the results you are seeing. They aren't acting purely as standard pins.


I just changed the program to use the SAMD pins as digital outputs.
D4=PB23, D5=PA27, D6=PA20, D7=PB22.
They operate correctly as digital output pins when fed a 100Hz digital on/off signal.
I did not change the wiring at all the pins are still connected to the LCD wires with the LCD in place.

I will now change the program back to the LCD display and see what happens.


Most peculiar.

D4=PB23, D5=PA27, D6=PA20 are operating correctly, so are r/s and en.
D7=PB22 is locked high. I am feeding characters that should cause D7 to rise and fall.
I made no change to the wiring layout apart from removing and replacing the PCB from its socket to re-program it.

I loaded the latest version of the LiquidCrystal library.

Pert said:

"Even if your board doesn't have an EDBG chip, if you're using it as a Zero, those pins are being manipulated in software in a manner which might cause the results you are seeing. They aren't acting purely as standard pins."

The only difference between PB22 and PB23 I can see is that one is TX and one is RX but they both operate as expected when treated as digital pins. Could it be something in "LiquidCrystal" is causing my problem? Sorry, I do not have the knowledge to check this presently.

One more time before I abandon this question. I am surprised that no one has dealt with a similar situation before.

Here are the variant.cpp entries under Arduino_zero for two of the pins I am using, PORTB22 and PORTB23.

// 30..41 - EDBG
// ----------------------
// 30/31 - EDBG/UART

Under test both of these pins will work as standard digital outputs correctly.
In trying to use them as LCD data lines PORTB23 works as planned, PORTB22 locks high.
Since the variant.cpp file is almost identical for both of the why should this be? Is there some other deeper system control settings I do not understand?

I tried editing PIN_ATTR_NONE to PIN_ATTR_DIGITAL in the variant.cpp file but this caused other errors in pincount(fn) and various SERCOM sections.



Does the problem still occur if you comment out these lines in variants/arduino_zero/variant.cpp?:

SERCOM sercom5( SERCOM5 ) ;




void SERCOM5_Handler()

Thank you Pert.

The 4th pin is now working. Something happened to upset the program because I had to comment out the Serial entries but that is another project.

I have been deep in studies on variants for the last couple of nights and I suspected the Sercom entries may have been the problem but I had no idea what to do about it.

I know this is probably very complicated but is there any chance of getting a couple of pointers to what was involved?

Thank you, Brian

The zero variant initialized the pins appropriately for a SERCOM connection to the Edbg chip.
To use them as gpio, you have to either prevent that, or undo it.

It MIGHT be easier to use a board definition that doesn’t have an edbg chip (arduino m0 or sparkfun samd21 breakout, for example), except I’m not positive that they have removed the SERCOM initialization, and iirc there’s a pin swap somewhere that may or may not be relevant.