AnsweredAssumed Answered

[LS1046A] Cannot change state of one of the GPIO lines (GPIO4[2])

Question asked by Maciej Pijanowski on Jun 26, 2019
Latest reply on Jul 9, 2019 by Maciej Pijanowski

Hello. We have an LS1046A based board. We are during the bring up process
and are validating the GPIO lines we need. We faced unexpected behavior
on one of the lines.

 

One of the GPIO (GPIO4[2]) cannot be set to OUT HIGHT despite writing to the
DIR / DATA registers.

 

This is the U-Boot code we use for this test:

 

```
/* GPIO4[2,3,10,11] */
val4 = (1 << 29) | (1 << 28) | (1 << 21) | (1 << 20);

 

read4 = in_be32(&pgpio4->gpdir);
printf("gpio4->gpdir before: 0x%x\n", read4);
setbits_be32(&pgpio4->gpdir, val4);
read4 = in_be32(&pgpio4->gpdir);
printf("gpio4->gpdir after: 0x%x\n\n", read4);

 

read4 = in_be32(&pgpio4->gpdat);
printf("gpio4->gpdat before: 0x%x\n", read4);
setbits_be32(&pgpio4->gpdat, val4);
read4 = in_be32(&pgpio4->gpdat);
printf("gpio4->gpdat after: 0x%x\n\n\n", read4);
```

 

This is U-Boot output:

 

```
gpio4->gpdir before: 0x0
gpio4->gpdir after: 0x30300000

 

gpio4->gpdat before: 0x0
gpio4->gpdat after: 0x10300000
```

 

As you can see, the GPDAT bit for GPIO4[2] is not being set.
I believe the pinmux for those pins is correctly set within the RCW. Both GPIO4[2,3]
are muxed to GPIO by the same single bit RCW[I2C_EXT] = 010.
So if the setting was incorrect, I would expect both GPIO4[2,3] to not operate.

 

We had similar issue for the GPIO2[26,27] and it turned out that we cannot have
them muxed to GPIO while having the QSPI_A_DAT3 enabled at the same time.
I could not find a similar issue for the GPIO4[2] in the reference manual.
Escpecially that muxing it is tied with the GPIO4[3], which works correctly.

 

Are there any other mechanism that would prevent this GPIO from operating? Thanks.

Outcomes