Pin A5 stays high when using Ethernet feather wing on Xenon

Hi guys,

I couldn’t find a solution on this via search and I’m probably doing something wrong but for some reason analog pin A5 on the Xenon stays high (around 3.3V) when I use the Xenon with the ethernet Featherwing and ethernet stack enabled for internet connection.

When I put the following in comment in setup(), pin A5 is low (0V) which is OK.


We use pin A5 to switch between 2 modbus channels. On our board we have a pull down and it works perfectly as long as we don’t load that ethernet stack.

Any ideas? Pin A5 isn’t used for ethernet so I don’t see where this is coming from.
I tried setting the pin via digitalwrite to low but doesn’t help much.

Thank you.

Kind regards,

Let me ping someone that might be able to help, @ParticleD, or @mstanley are you able to assist?

I tried what you describe, and for me A5 stays high no matter what I do in code (i.e. with our without the two Ethernet code lines you mentioned).

I am baffled as to why that pin is high ONLY when the Xenon is plugged into the Etherwing. It’s not high with the Xenon plugged into a breadboard, and it’s not high if I power up the Etherwing via 3V3, but don’t put the Xenon on it. According to the schematic A5 is not connected to anything other than the other mesh socket’s A5.

I need to confer with some folks about this. Maybe I’m missing something super simple but… Well I can’t figure it out.

Mo’ latah’.

1 Like

Just a quick update – we’ve asked some of our technical folks in China to take a look at this issue. It will be interesting to hear what they say about it! But it might take a day or two.

Thanks for the reply. It seems to be only when the Ethernet wiznet stack is loaded in combination with the nRF52840 processor. We’ve been looking into the source code and we suspect the wiznet driver puts the SPI_SS (or A5) port to OUTPUT when this combination is loaded although we didn’t had the time and resources to find the exact location. Happy hunting!

Thanks for that! I passed that along to the team that will be investigating this issue.

Fixed in this PR: :slightly_smiling_face: