TRM on 16 bit address data mux

Thanks, Biser,

but It's not clear yet. I'm want to connect a SRAM 16 bits in the GPMC BUS in multiplexed mode.

If nothing have changed, in "Multiplexed Address Data 16-Bit Devices" mode:

signal GPMC_AD[0] (pin U7) carries "GPMC_D0" along with "GPMC_A1"

signal GPMC_AD[1] (pin V7) carries "GPMC_D1" along with "GPMC_A2"

...

signal GPMC_AD[15] (pin U7) carries "GPMC_D15" along with "GPMC_A16"

signal GPMC_A[0] (pin R13) is not used in this mode,

signal GPMC_A[1] (pin V14) carries "GPMC_A17" in this mode,

signal GPMC_A[2] (pin U14) carries "GPMC_A18" in this mode,

and so forth? Is this correct? A send part of my schematic ...

Thanks again.

Luis

Thanks again, Biser.

I will proceed as you recomend, including not connecting CE, BHE and BLE. Connecting the pins in SRAM to GND.

But, please explain, why in TRM do we read things like:

My purpose is make more clear the reading of TRM.

Thanks in advance.

Luis

Luis, we are going to add the following note below table 7-5 in the TRM:

Note:  The values in this column represent the signals on the memory.  Be aware that some 16-bit memories may label the address lines differently.  Some label the LSB as A0 ,while others use A1 for the LSB.  These columns assume the LSB is A0. 

As Biser states, it is difficult to document the connection for all memories, because some memories use A0 for 8-bit boundary, and some use A0 for 16-bit boundary.  On the processor, A0 is always on the 8-bit boundary (regardless of whether you chose 8-bit or 16-bit mode in the GPMC controller).

Hopefully this clears it up.

Regards,

James

Dear Biser and James,

I understand your difficulties in placing a "universal" information on table 7-5, and would like to thank you for support this discussion.

I think you would have more success if you assumed that the info in that table were the signals of the processor that is carried by the PIN. It lacks that fundamental information of the pin (in my point of view), the physical entity, that in function of the muxing input info, releases this or that "processor signal". This would be  much easier.  In addition you make clear that the A0 processor signal is always in a 8-bit boundary. So in the columns of 16 bit devices the A0 processor signal is not required, its function would be assumed by BHE and BLE (if so). I really don't know if you offer this pin in a 16 bit mode, if so, OK, it would be in the table even in 16-bit modes. And we won't have that confusing info like that in table 7-4! ( My only purpose writing the above is to contribute to improve the documentation.)

Biser, offered me a clear table of connections. But, my peripheral is a 16-bit boundary oriented device. So I have 19 address lines (A0 - A18).

Just to have a final documentation to the forum, and clear any doubt, please confirm my connection table below to a 16-bit boundary oriented device:

Biser,

I think it's OK. But we have a final question.

Really think you (TRM group) should change your way of look to table 7-5 and rewrite it from the view point of the processor, forgetting the many memories. Think the examples could be more numerous and using signals on the view point of the processor.

Just to finish, even if we wire our signals to comply with 16-bit muxed mode, can we still make byte accesses?  Stating this another way, to ensure access of char variables in "C" is it necessary to wire BHE and BLE to the memory? Where can I read about this issue?

Thank you very much,

Luis