OMAP-L138: The problem of EMIFA access

It's years since I used a 16-bit flash on an OMAP-L138, but that sounds correct to me.

The lowest order address bit connected to a 16-bit device should be OMAP EMA_BA[1], which would connect to A0 on your 16-bit flash device. Next you'd connect OMAP EMA_A[0] to flash address A1, EMA_A[1] to flash A2, and so on.

You get two bytes returned with each read, so divide the number of address bits you'd require for an 8-bit read by 2. So the entire address output would be A3. But remember the lowest of these bits is output on BA[1], so you'd see 51 on the EMA_A[15:0].

Regards, Jon.

I am not a TI guy either. Cvetolin's reply saying that TI guys are to respond sort of makes non-TI guys assume that the issue is being handled.

I used the EMIF controller several years ago and I found it puzzling until I figured out it does not shift the address at all for Asynchronous Memory.

The OMAP-L138 has pins up to EMA_A[22]. The mapping of pins to written address would be:

EMA_A[22] = Address[24]
...
EMA_A[15] = Address[17]
EMA_A[14] = Address[16]
EMA_A[13] = Address[15]
...
EMA_A[0] = Address[2]
EMA_BA[1] = Address[1]
EMA_BA[0] = Address[0]

Assumes ASIZE=0 or 8-bit. With ASIZE=1 or 16-bit, the EMA_BA[0] line is repurposed to the highest address line. The mapping would be:

EMA_BA[0] = Address[25] <-- assumed
EMA_A[22] = Address[24]
...
EMA_A[15] = Address[17]
EMA_A[14] = Address[16]
EMA_A[13] = Address[15]
...
EMA_A[0] = Address[2]
EMA_BA[1] = Address[1]
X = Address[0]

Note that the mapping has not shifted. The repurpose of EMA_BA[0] has been discussed a few times on this forum. It may or may not work. The TRM says that EMA_BA[0] becomes a virtual EMA_A[22] but a physical EMA_A[22] already exists. I am guessing that is typo error. I have not used this feature to confirm.

As Jonathan as noted, a TI guy can confirm.