8-bit access on 16-bit GPMC device

That is correct.

Regards,

MichaelT

Thanks

Hi Michael,

I assumed this behaviour too, but - unfortunately - I get BE0 and BE1 only working at write access.
While reading both are low all time.

This is no problem with byte access to a 16-bit SRAM (one byte is read and ignored),
but I need a real 8-bit interface and I used BE0/BE1 in my FPGA to mux the data to one 8-bit-bus.
This doesn't work now.

Any idea?

Thanks in advance

Why not just set GPMC_CONFIG1_0[DEVICESIZE]=0 (8-bit)?

1) Table 7-5 in manual  spru73i.pdf, p. 269 implies multiplexed mode is available for 16-Bit devices only

2) I checked it out: BE0 is fixed 0 and BE1 is fixed 1 now

I didn't realize you were using the multiplexed mode of operation.  The combination of "muxed" and "8-bit" does not appear to be one of the use cases envisioned by the designers.  This use case is therefore not validated or tested by TI.  Can you switch to non-multiplexed 8-bit interface so that you're using one of the supported modes?  That would be the safest approach.  There's a small risk that if you're using an unvalidated combination that there might be some kind of timing issue, e.g. you might only see it on extremes of process and/or temperature.

Non-multiplexed mode is not possible, I need this pins for other functions.

My question is:
Did I something wrong or is the manual wrong: Figure 7-15 (spruh73i, p.297) shows clearly AAD read access with valid BE0/BE1. But in my case BE0/BE1 are always low while read cycle.

(out of topic: There was already an other missunderstandig regarding an AAD figure:
http://e2e.ti.com/support/arm/sitara_arm/f/791/p/308624/1075925.aspx#1075925)

(PS: Sorry for possibly poor english)

There are 3 different configurations related to multiplexing:

• Non-multiplexed
• Address-data multiplexed
• Address-Address-Data Multiplexed

Which of those are you trying to use?  And since 8-bit data is only officially supported with non-multiplexed configuration it sounds to me like you were trying to do something "creative" to utilize the 16-bit interface.  Is that correct?  Can you summarize how you were trying to use the 16-bit interface to connect to an 8-bit device?

I use AAD-Muxed mode;

This works fine with a 16Bit SRAM at CS1, AD[0..15]  as data, A[1..20] as address + BE0, BE1

parallel I want to drive 8-bit periphery at CS2;  The gates and direction are driven by a PLD,
depending on BE0, BE1, RD, WE;
It works writing but not reading, cause BE0 and BE1 are not driven in read access.

Bastian Suess said:

It works writing but not reading, cause BE0 and BE1 are not driven in read access.

As far as I can see, the byte enables are both driven during reads.  (These are active-low signals, so "driven" corresponds to "low".)  Does that correspond to what you're seeing?

1) Missunderstanding :-(

as mentioned in post from Feb 11: both signals are low all time, so I can not distinguish from outside, if the software does "read even byte from address 0" or "read odd byte from address 1" or "read word from 0".

2) have a look at Figure 7-15 (spruh73i, p.297): This shows clearly AAD read access with BE0/BE1
    "Always low" looks different.

Hi Bastian

Do you have a solution to the problem?

We using 16bit address data mux mode and are signals BE0/BE1 working correct when we writing byte, but they are not working when we reading byte.

Best regards

Nikolay

That's how reads in the 16-bit muxed mode are designed to work. 

Hi Brad

We using shell in WEC7 with commands In8 and Out8. It is simple access to physical memory without programming. After writing the first message I looked source code of shell and I have thought that the problem may be with him.

Similarly, it will be clear on Tuesday when I have a couple of tests.

Best regards,

Nikolay 

Hi Nikolay,

I decided to omit A0 and shift the address bus. Only byte accesses on even addresses are possible now
("holes" resp. mirrors are on odd byte addresses).

This causes an ugly software, but in my case it will work (hopefully)

Hi Brad,

this sounds like you are proud of this (?)

How about a statement regarding Figure 7-15 (spruh73, p.297)

Bastian Suess said:

this sounds like you are proud of this (?)

I'm trying to be factual.  There was no "pride" in my previous answer.

Bastian Suess said:

How about a statement regarding Figure 7-15 (spruh73, p.297)

Hang on...  I might have missed a subtlety with regard to the behavior on my first read.  It sounds like for the case of a SINGLE read that you should in fact get valid BE0/BE1 behavior.  How do you have this address space mapped in the ARM MMU?  Have you tried it as strongly ordered memory?  In the case of multiple reads both signals are asserted low, but in the case of a single access they should be valid.

Hi Brad,

I'm not a native speaker, so it is sometimes difficult to "read between the lines".
"That's how reads in the 16-bit muxed mode are designed to work. " sounds like it is o.k. that
reads doesn't work and the docu tells something different.

Now I checked the compilers asm-output: there is indeed only one single "STRB"
and I tested some other MMU configurations (Cache was already disabled), without success.

current state (Defines from Starterware):
MMU_MEMTYPE_NORMAL_NON_SHAREABLE(MMU_NON_CACHEABLE,MMU_NON_CACHEABLE)

MMU_MEMTYPE_DEVICE_NON_SHAREABLE     => WR: no Chipselect, RD: hangup
MMU_MEMTYPE_DEVICE_SHAREABLE, => no different to _NORMAL_ above.

I did not find a good description for the MMU, do you have any info about theses bits?

Hi Bastian,

Thanks for reply.

Today we have found an interesting thing. If configured. in mux 16 bit mode, pin GPMC_A0 as signal GPMC_A0 it allows to read the bytes from odd addresses, without shifting address. I know that it goes beyond the documentation, but for us it gives to debug drivers. Maybe it will help you.

Best regards,

Nikolay Semko

Hi Nikolay,

thanks for this great hint!
Unfortunately I need this pin for the 2nd Ethernet port and I did not found an other pin mux possibility.

BTW and JFYI:
setting the device size in GPMC_CONFIG1 to "8 Bit" in mode AAD-mux
causes 16-bit-accesses are segmented in 2 byte accesses. I did not checked it further.
This is "out of specification" too.

best regards
Bastian