Hi,
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi,
This is real operation our board.
We used the capture equipment.
What is the problem in our board or firmware?
Thanks & Regards.
The silence from TI is telling. Not much to add. Some observations.
The documentation states "Additionally, when the EMIFA interfaces to a 16-bit asynchronous device, the EMA_BA[0] pin can serve as the upper address line EMA_A[22]." I thought this was a reference to the OMAP-L138/C6748 but on that chip, EMA_A[22] exists as a real pin. For CS2, adressing 0x60000000 to 0x61FFFFFF would require 25 bits address with 8-bit data and 24 bits with 16-bit data. Implied is that EMA_BA[0] would be EMA_A[23]. Some more examples here:
http://processors.wiki.ti.com/index.php/Connecting_NOR_Flash_to_OMAP-L138
In those diagrams, the EMA_BA[0] is never used for EMA_A[23]. Memory sizes that need EMA_A[23] use other CS for banking.
I would hazard to guess that BA[0] as EMA_A[22] feature is not implemented. Maybe try accessing the highest possible memory for CS2, 0x61FFFFFF, to see if EMA_BA[0] is really EMA_A[23]. Workaround would be to drive EMA_BA[0] as a GPIO and access your device as two banks of 32KB.
Any resolution to this question? I would like to use a 16bit by 32MB NOR chip on an OMAP L-138.
Hi Richard,
Please refer to the following TI wiki page for hw connection 32MB 16bit NOR flash.
processors.wiki.ti.com/.../Connecting_NOR_Flash_to_OMAP-L138
Titus,
Thank you for your response. Your link confirmed my understanding of how to make the connection. Turned out that my problem was the hardware was missing two address line connections. Once that was fixed it worked fine.
Richard.