change GPIO startup state

[siteswapjuggler]

Hello,

I'm working on a project which include a microcontroller and a NanoPi NEO Core running  Armbian FriendlyCore distribution. The NanoPi is wired to the µcontroler ICSP which can reset the µcontroller for update purpose. The allwinner H3 datasheet state that the GPIOA6 (the one linked to ICSP) should start with HIGH-Z and no resistance pulling, it seems to do so but a few second after reboot it seems to go low as all other GPIO... resulting in an unwanting reset of the µcontroller.

Is there a way to change this by setting the default state somewhere in the system, or should I have to use dts files or core compilation ? Any solution would be appreciated.

Thanks for your help
Sylvain

[Werner]

11 hours ago, siteswapjuggler said:

Armbian FriendlyCore

What?

[Werner]

Providing logs with 

armbianmonitor -u

 helps with troubleshooting and significantly raises chances that issue gets addressed.

[siteswapjuggler]

Hello,

FriendlyCore is a derivation of Ubuntu Core use by the manufacturer of the NanoPi, so unfortunately no armbianmonitor on it. But as a arm linux system it's very close to armbian which has the biggest community so. While continuing my research, I was hopping to get enough information from to community to complete my searchs and then work from there.

My aim is to get more information about the kernel process, when and how it take control of the GPIO, and how to modify the default behaviours.

Sylvain

[going]

19.06.2023 в 22:50, siteswapjuggler сказал:

The allwinner H3 datasheet state that the GPIOA6 (the one linked to ICSP) should start with HIGH-Z and no resistance pulling

See doc:
********************************************************************************
https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt
********************************************************************************

sudo apt install gpiod libgpiod2

See manual:
+++++++++++++++++++++++++++++++++++++++++++++
* gpiodetect - list all gpiochips present on the system, their names, labels
               and number of GPIO lines

* gpioinfo   - list all lines of specified gpiochips, their names, consumers,
               direction, active state and additional flags

* gpioget    - read values of specified GPIO lines

* gpioset    - set values of specified GPIO lines, potentially keep the lines
               exported and wait until timeout, user input or signal

* gpiofind   - find the gpiochip name and line offset given the line name

* gpiomon    - wait for events on GPIO lines, specify which events to watch,
               how many events to process before exiting or if the events
               should be reported to the console

 

[going]

19.06.2023 в 22:50, siteswapjuggler сказал:

but a few second after reboot it seems to go low as all other GPIO... resulting in an unwanting reset of the µcontroller.

Allwinner processors in the kernel do not have their own driver, but a common one is used. This driver doesn't exactly match the hardware implementation.
Resetting the GPIO level and then returning to the initial state in some situations is a fixed fact.
But you write that all GPIOs change the level when the device is rebooted. This should be taken into account when developing your composite device and either include various interconnected devices in a certain sequence. Or provide a communication relay and turn on the connection when all transients on the pins of the device have ended.

[siteswapjuggler]

Hi and thanks a lot for your answer, I did not find a solution to change default behaviour but I still succeed to get past this problem by changing my schematic and adpatig avrdude configuration for ICSP programming as mention in this post : https://electronics.stackexchange.com/questions/606593/invert-avrdude-signal-for-reset-pin

Thanks a lot for your time and guidance.
Sylvain