GPMC_A11 always high on AM335x

Hi,

Please check if the pinmux for GPMC_A11 that you need does not get overwritten later in the code.

Have you read the actual value of the pinmux register? Address should be 0x44E1_08EC. You can use devmem2 command to read it.

There are 2 different pins where gpmc_a11 can be used.  The mux register you're focused on corresponds to R6.  It's also pinned out to V17.  Which pin is it that you're looking at?

It is designed as generally low-speed (relatively) parallel bus, currently used for UART, general I/O, and SRAM access.

After many attempts to solve this issue without success, I am inclined to believe there is a bug in the chip, unless someone can convince me it isn't.

Which chip select is this for?  Can you use devmem2 to print out all the corresponding GPMC_CONFIGx registers?  Please include the complete printouts so I can see the addresses you're reading.

I suspect that somehow the GPMC may have had its configuration over-written and that you're not in the 8-bit non-multiplexed mode as you expect.

Also, what address are you accessing to read from the GPMC?  If for example your math is incorrect with respect to how you're performing the accesses then the GPMC might be using the configuration from another chip select space.  Can you confirm that the expected CSn signal is asserted when performing the access?

Hello Brad,

Please see the pin configuration table as requested. The GPMC is used in conjunction with CS3 and CS5. I have cross-checked that all pins were used as intended. As you can see, I am not using the default A11 pin as A11 signal, but the alternate function of the LCD_AC_BIAS_EN pin.

I used GPMC from 0x000 to 0x0fff, i.e. the entire range.

I am able to communicate with the UART chips without issues after masking off the A11 pin, the CS3 and CS5 are working perfectly. In fact A0 to A10 are working perfectly, except A11, which is always HIGH.

That's not the data I was looking for.  I want to view your GPMC configuration:

Please use devmem2 to interrogate registers like the ones above corresponding to the chip selects of interest.

K H Tang said:

gpmc_ad044E10800000000300gpmc_ad0gpmc_ad144E10804000000300gpmc_ad1gpmc_ad244E10808000000300gpmc_ad2gpmc_ad344E1080C000000300gpmc_ad3gpmc_ad444E10810000000300gpmc_ad4gpmc_ad544E10814000000300gpmc_ad5gpmc_ad644E10818000000300gpmc_ad6gpmc_ad744E1081C000000300gpmc_ad7gpmc_ad844E10820000000300gpmc_ad8gpmc_ad944E10824000000300gpmc_ad7gpmc_ad1044E10828000000300gpmc_ad10gpmc_ad1144E1082C000000400gpmc_ad11gpmc_ad1244E10830000000400gpmc_ad12gpmc_ad1344E10834000000400gpmc_ad13gpmc_ad1444E10838000000400gpmc_ad14gpmc_ad1544E1083C000000400gpmc_ad15

Your chart shows that you're using gpmc_ad0 - gpmc_ad15.  Your original post mentions you're trying to use 8-bit non-muxed mode, but your chart looks more like a 16-bit multiplexed mode.  In the 16-bit multiplexed mode GPMC_A11 is not used, so your observations match very well with that.  And that's why I'd like to see the GPMC register configuration.  I want to know whether you're in a muxed mode of operation or non-muxed.  Also, I want to know that the chip select is being asserted as expected so that we can be certain that the registers we examine are the ones governing the access.

Brad,

I omitted some detailed info in the previous posts to avoid confusing.

I actually have the following configurations:

CS0 - NAND

CS1 - AD Multiplexed 16-bit

CS2 - AD Multiplexed 16-bit

CS3 - Non-multiplexed 8-bit

CS5 - Non-multiplexed 8-bit

The GPMC configurations are shown below:

Are these values being dumped with devmem2 at run-time, or are these the values that you are attempting to program with your code?  It is far preferable to see the run-time values with devmem2.  In particular for now the GPMC_CONFIG1 values for the chip selects of interest are the most important.

K H Tang said:

CS3 - Non-multiplexed 8-bit

K H Tang said:

GPMC_CONFIG1_3 500000F0 00401000

Your register value above corresponds to a non-multiplexed 16-bit configuration.

Do you have access to other pins like A12 and higher?  Are they operating as expected?

Brad,

Yes, these values are obtained at runtime. I documented them for reference purposes.

Oh sorry the CS3 was a mistake. I shall correct it.

My current design uses up to address A11 only, but I may have chance to pull GPMC_A12 out for testing. I shall experiment it, finger cross.

I have configured ball U2 and U3 to be GPMC_A13 and GPMC_A14 respectively, and the result is the same, they all remain at high level.

It looks like addresses higher than A11 are always high in my case for 8-bit non-muxed.

Any idea?

Did you fix your CS3 configuration?

What other signals do you see toggling?  Specifically I would like to know which CSn pin you see asserted while you are looking at these address pins.  What is the physical address you're accessing to trigger the access?

Yes, both CS3 and CS5 now look like this:

When I access CS3 and CS5 at mapbase of 0x1000000 and 0x2000000 respectively, everything seems to work as expected except that A12 (and now A13 as well) are always high. So I have to mask out these address pins (since they are not really being used now) in the PLD. With that I can talk to my 16T654 UART (Linux in-built driver 8250.c) chips perfectly. What I did was to add this device using platform_add_devices function.

Still no one has any ideas?

I think this must be the.... BINGO!

I will verify this and post the result.

Glad we finally figured it out! Thanks for the update.