DM365 AEMIF with multiple CE

Marco Braga said:

My idea is to use current CE0 to select the NAND chip (no change from EVM setup) and connect CE1 to DM6435's SPI along with required signals. But since the AEMIF controller is the same, I am not sure if "normal mode" and "NAND flash mode" can be used at the same time or in mutual exclusion or what involves switching from one mode to the other.

This sounds like the best idea, the two chip selects have individual controls, one can be enabled for NAND and the other for a generic asynchronous interface (by way of NANDFCR.CSxNAND bits), so you should be able to have both going with their own individual internal address spaces and configurations.

Marco Braga said:

I've checked DM365's AEMIF document but I am not sure of what will this setup impact at driver level. I'd like to preserve current MTD functionality and add communication through AEMIF/HPI on the other chip select.

In theory if the MTD driver is only using a single CE space than you should be able to write your own HPI driver to work along side it, though you would have to take a closer look at the MTD driver source to ensure that it is not putting in an EMIF configuration for both CE spaces, or just try out your own HPI driver and see if the MTD driver impacts it when both are linked in. In any case it should not be too difficult to get both to work side by side, the bigger part would be putting together the HPI driver itself.

Bernie,

thank you for your prompt reply!I think that current EVM board uses both chip selects to access a 2Gbit flash, but we can use a smaller NAND chip and use only one of them without problems. Modifications to the driver for this should not be very difficult.

Then basically I can let the MTD driver configure the NAND registers for CS2 and use CS3 as AEMIF. I am still not sure how other (shared) registers must be configured for this case, but from a quick look it seems only AWCCR is shared. Configuration registers are "per CS" so they should not pose a problem.

Thanks!

Just to complete the scenario, before going with AEMIF/HPI we tried to connect DM365 and DM6435 using SPI but it's been a failure. DM6435 can only boot in SPI master mode and DM365's only slave SPI port is SPI4. But it seems that this port is lacking EDMA events and IRQ lines so basically it must be used in PIO mode.

Since DM6435 expects to boot from an SPI EEPROM it comunicates using EEPROM protocol (command, high address byte, low address byte, 8 bit data) but I've been unable to provide the requested byte in time. Basically after receiving the second address byte I have to decode it and provide the corresponging data byte before the next SPI clock cycle. This proved to be too difficult to do with the requested timinigs.

Last effort has been done with UART without HW handshaking but again this resulted in failure since I suspect missing HW flow control caused bytes to be lost during communication.

Hi Bernie,

should we decide to go for this option (AEMIF/HPI), we would like to de-risk our design. Is there any option we can follow to have an evaluation of it? Perhaps someone in TI can have a look at it or perhaps we can share the design and have suggestions from you?

Marco Braga said:

Is there any option we can follow to have an evaluation of it? Perhaps someone in TI can have a look at it or perhaps we can share the design and have suggestions from you?

For a more 1on1 evaluation you would probably want to work with your local TI contact or ask through http://support.ti.com as that will get you someone in your local region to look over the design. Keep in mind that in general any reviews will be unofficial and not guaranteed, for a more thorough review you would want to contract a consultant or third party for engineering services.

I would be glad to take a look at and comment on anything you can post here though.

Hi Bernie,

This is how we think to connect HPI/EMIF. Since every advice is always welcome, I'd like to have your unofficial comments on this. If you spot any evident error please let me know. What's puzzling us most is what to do with HRDY signal. There is a BUSY signal on EMIF but it is already connected to the NAND flash so we are not sure if HRDY is really required and if it's possible to connect it to HRDY too.

Thanks!

HPI (DM6435)                    EMIF (DM365)

HCSn                                     EM_CE1
HR/Wn                                 EM_A3
HCNTL[1:0]                         EM_A[4:5]
HHWIL                                  EM_BA1
HASn                                     PULL-up             
HINTn                                   GPIO
HD[15:0]                              EM_D[15:0]
HRDYn                                  NC (setting proper delay for the setup/hold time) OR EM_WAIT (SHARED WITH NAND ON EM_CE0)

The HRDY signal must be interfaced with the EM_WAIT signal on the EMIFA, this signal is very necessary, as accesses to the HPI memory map are not deterministic and can take arbitrarily long. For example lets say you use HPI to access a particularly slow flash device attached to the DM6437, than the HPI needs to de-assert HRDY until it has the data available. Another example would be if your system was particularly busy when you made a HPI request, the DM6437 may need additional time to request the data if the internal bus is busy. You can probably get away with a simple buffer externally to manage the connection of the NAND and HPI signals to EM_WAIT such that you do not end up with any inadvertent bus contention, I would not recommend connecting them all together directly.

Your other connections look ok, though I do not see connections for the HDS data strobes which should be interfaced with EM_OE and EM_WE.

Bernie you are right about EM_WAIT, this is our proposal for it:

WAIT = NAND_R/Bn AND [NOT (HRDYn)]

Using multiple-function gate SN74AUP1G97 with this pin mapping:

PIN A -> GND
PIN B -> NAND_R/Bn
PIN C -> HRDYn

What do you think, might it work?

Thanks!

I believe you would need something more like EM_WAIT = NAND_R/Bn OR [NOT (HRDYn)] since the EMIF will need to wait if either the NAND or the HPI is requesting additional wait states, since the EM_WAIT signal has programmable polarity you just need to ensure that the two ORed signals match polarity. So I think the below would work:

PIN A -> NAND_R/Bn
PIN B -> Vcc
PIN C -> HRDYn

Though this would work it has a risk in that if either the NAND or the HPI get into a state where the EM_WAIT is constantly asserted than neither interface will operate, so you may want to add additional logic to take into account the chip selects as an alternative if you had two buffers one for each EM_WAIT source that were gated by the associated CE line that would work as well and would be protected in the case that one of the devices EM_WAIT line gets stuck (something like EM_WAIT = [NAND_R/Bn AND CE0] OR [[NOT (HRDYn)] AND CE1] though the central OR can just be a split as the CE lines are guaranteed to be mutually exclusive).