Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

output value of GPIO pins at power on? #4

Open
pdp7 opened this issue Apr 27, 2021 · 3 comments
Open

output value of GPIO pins at power on? #4

pdp7 opened this issue Apr 27, 2021 · 3 comments

Comments

@pdp7
Copy link
Collaborator

pdp7 commented Apr 27, 2021

BeagleV beta developer @tommythorn raised concern about output enable as the default for the GPIO pins:
https://forum.beagleboard.org/t/datasheet-on-the-soc/28882/15

Looking at the latest JH7100 datasheet (01.01.04 dated 2021-4-21), under GPIO we read
" Individually programmable input/output pins. Defaults to output at reset."
Is that true? That would mean anything driving an input would be fighting the chip until firmware configures the GPIO as an input. Am I missing something?

I asked what type of external GPIO circuits this could cause a problem for:

Literally anything that drives the GPIO with a opposite level of whatever it defaults to. This seems highly unusual. Normally GPIOs are tristated (or inputs) until configured.

I agree looking at the JH7100 datasheet that it does seem to be the case that output enable is on by default for the GPIO pin group.

@MichaelZhuxx If you are able to assist, then I would like clarification on this:
What is the default output value for those GPIO pins at power on? Is it high or low?

@pdp7 pdp7 changed the title clarify the state of GPIO pins at power on output value of GPIO pins at power on? Apr 27, 2021
@pdp7
Copy link
Collaborator Author

pdp7 commented Apr 27, 2021

Update from StarFive:

From our cspec , for the PAD_GPIO*, the default output enable pins will be active as low value

@tommythorn so I believe that while they will be output enable the output value will be low.

@pdp7 pdp7 closed this as completed Apr 27, 2021
@pdp7 pdp7 reopened this Apr 27, 2021
@tommythorn
Copy link

Thanks for the confirmation. It doesn't change that this is unusual and surprising. I imagine it will cause problems down the line.

@pdp7
Copy link
Collaborator Author

pdp7 commented Apr 29, 2021

Additional information from StarFive:

Please refer the Table 11-1 in the datasheet,after power up or reset , all the IO cell's pin will be configured to be the Default value ( the right column of the table)

Then , the Function IO share with interface group (physical IO PAD sharing) will be programmed to the default function ( Function 0) by uboot : such as , PAD_GPIO* is for GPIO signal .

meanwhile , the gpio full mux controller (logic IO signals sharing ) will be programmed as Table 11-4's default function , each GPIO signal is configured to the desired logic signal of the interface

So some of them are input ones, some of them are output ones , some of them are Bi-direction ones. The status of the IO PAD depends on the signal logic connect with .

For example :

Case1 : gpio full mux controller , setting SPI2AHB_D0 for GPIO31, Function IO sharing group, setting Function 0 , so the PAD_GPIO[31] is for SPI2AHB_D0

Case2 : gpio full mux controller , setting SPI2AHB_D0 for GPIO31, Function IO sharing group, setting Function 6, so the PAD_FUNC_SHARE[31] is for SPI2AHB_D0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants