K60120M NAND Flash with External SRAM on flexbus, NFC, Ready/Busy RB

[pmt]

I'm doing a design that requires an external single NAND flash (8-bit) and SRAM (16-bit).  The NAND flash controller shares many of the same flexbus pins.  In reading some of the older posts it looks like arbitration is handled between the Flexbus and NAND Flash peripheral such that you should be able to run both.  

Except it looks like two pins MUST be dedicated w.r.t. the NFC:  NFC_CEx_b and NFC_RB*.  Can anyone please confirm?

CE needs to be dedicated because it controls the chip arbitration.  RB needs to be dedicated because it may stay actively driven even after NFC_CE goes inactive during a flash erase or program cycle (I can't imagine locking the flexbus for entire Ready/Busy cycle, which can be many milliseconds).

The big issue for me is that I am using the upper bus byte selects for my SRAM (BE23_16 and BE31_24).  This directly conflicts with RB and CE0_b lines, which are not available on any other pin.  CE1_b is available on BE15_8, which I don't use.

So my question are: 

- Can I seamlessly use NFC_CE1_b instead of NFC_CE0_b

- What is the impact of not having the RB- line available to the NFC?  Am I losing anything?  Does the NFC state machine use this line? 

I could take the RB line and simply bring it to another I/O port, and even generate an interrupt on a transition. 

Is this just an oversight of the FreeScale engineers?  Seems that RB should be able to be routed to BE7_0 as an alternate pin location.

PMT

[pmt]

So I guess the mux'ing gods are laughing at me this morning.  Not having any flexibility on the RB line or byte selects is a shame.  To use the lower bus channel for SRAM (and lower byte selects) requires adding a big honking 16-bit bus latch on the flexbus for the ALE cycle.  Routing data on the upper bus does not have this requirement.

The thing is the need for NAND flash and need for added external memory are not mutually exclusive.  It's a shame this one line is blocking the use of the NFC in my instance.  But is the RB truly a NFC hardware requirement?  Can't I poll the RB line in software instead for most operations before issuing an erase or page program? 

The key element I am looking to get out of the NFC is the FEC computation for processor offload.  I'd be happy to bit bang all the other control signals if needed.    

PMT   

[Kan_Li]

Hi Pmt,

Maybe you have some misunderstanding about the product usage, but there is no need to add a big honking 16-bit bus latch on the flexbus interface, the TWR-MEM provides a good reference for the case of using the lower bus channel for SRAM, in which no BExx_xx signal is used, please kindly refer to the following for details.

Hope that helps,

Have a great day,
Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[pmt]

Kan,

Thanks for the example. 

The 16-bit latch comes from the fact that when routing data on the lower bus Address and Data are multiplexed on AD0-15, whereas when routing on the upper bus Address and Data are muxed on AD31-16.  In the first case I need to latch AD0-15 (16-bit).  In the latter case I need to only latch AD16 to ~AD23 (8-bit latch depending on memory size) or even no latch at all since A16 to A23 are also available on pins separate from AD16 to AD23 on the 144-pin package.

In your example the interface is an 8-bit databus.  Thus the A0 line can be qualified with decode logic for odd and even bytes.  But this won't work with a 16-bit bus which needs independent control of the upper and lower byte on write cycles.  

The K60 memory cycle is already at a big disadvantage since redundant ALE cycles can't be suppressed (except in burst mode), and I would not want to sacrifice the performance of using an 8-bit data bus over 16.

So, is it possible to utilize the FEC engine of the NAND flash controller without the need to hook up RB?

PMT

[Kan_Li]

Pmt,

Providing you are using MR2A16ACYS35 as well, the upper bytes FB_D31-D16 are for SRAM, and FB_BE23_16 should be connected with LB signal, meanwhile FB_BE31_24 should be connected with UB, but for the sake of NFC interface, you may use FB_A0 instead of FB_BE_23_16, so that releases NFC_RB signal, and NFC_CE1 can be connected with Nand flash's chip select signal instead of NFC_CE0(FB_BE31_24).

Please kindly let me know if you have any issue.

Have a great day,

Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[pmt]

Kan,

The MRAM example is a 16-bit devices, but only hooked up in your example as an 8-bit data path.  As you said, I can extend this to use a 16-bit data bus, but your A0 solution does not work in this case.  Why? The A0 trick only provides two latching states:

     Latch 8-bits, odd address

     Latch 8-bits, even address

But for a 16-bit data path you need to latch three states for data writes:

  Latch only 8-bits, upper bus (odd address)

  Latch only 8-bits, lower bus (even address)

  Latch 16-bits, upper and lower bus

You will see all three modes for writes and a 16-bit data path.

PMT

[pmt]

I should amend my statement.  If the SRAM is in cache-able writeback memory the memory controller will do a 16-bit read-to-write cycle eliminating 8-bit access on writes..  That is, on an 8-bit write and 16-bit only bus the cache controller will first read a word, modify a byte, and write the word.

This is not the case for:

  Write-thru cache-able area

  Non-cache-able area

  DMA transactions to external memory

You NEED the upper and lower byte selects.  I see no way around it.

PMT

[Kan_Li · Accepted solution]

PMT,

I think you might have misunderstanding with my "A0 trick", in my solution, FB_A0 is connected with LB, and FB_BE_D31-D24(NFC_CS0) is connected with UB, so both of them provide three states for data writes:

  Latch only 8-bits, upper bus (odd address)

  Latch only 8-bits, lower bus (even address)

  Latch 16-bits, upper and lower bus

NFC_CE1 is connect with Nand flash's CS signal, and FB_BE_D23-D16(NFC_RB) can be released for NFC interface as well.

The only problem might be in accessing a 16bit space with misaligned address, for example, accessing address 0x0001 with 16bit width manner, but I think this can be prevented by link file and source code, right?

Take care that FB_ADx will be floating during non flexbus transfer cycles. It should be pull up.

Hope that makes sense,

Please kindly let me know if you have any issue.

Have a great day,
Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[pmt]

Kan,

OK, I get it now.  Thanks.  The misaligned transfers usually aren't a problem.  Many micro-controllers don't even support such a bus cycle.  You can usually set a compiler option to generate extra code to avoid misaligned access.  Same care would have to be done with the DMA transfers.   

Still, it would be nice if all this could be avoided by allowing some flexibility to move RB to an upper or lower byte select.  Same with NFC_CS0.  It would save some glue logic.

PMT  

[Kan_Li]

Pmt,

I think maybe you have some misunderstanding for the above example, the MRAM is a 16bit device, here we use D0-D7 connected with the 16bit port so that we save the total pins used by flexBus, and A0 line acts as the BE signal for upper and lower byte, so that the pin used for BE signal can be used as other function, for example, the RB signal for NFC module, and if you don't have such kind of concern for the pin number limitation, you may connect D0-D15 to the MRAM device, other connection can still keep the same as TWR-MEM.

Have a great day,
Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[Kan_Li]

Hi Pmt,

K60120M does implement an arbitration scheme that allows for sharing between the FlexBus and NFC; however, this sharing is really only used for the NFC data lines/FlexBus AD lines and the NFC_WE and FlexBus R/W signals. If you look at the signal muxing table in the manual you can see that these pins only have a single function selection for FlexBus/NFC.  For example, PTB20 function ALT5 is “FB_AD31/NFC_DATA15.” So this is a case where the pin is configured for a FB/NFC mode and dynamically switches between the two.

In the case of the control signal pins that you mention (NFC_CE0 and NFC_RB) the pins for these signals have different programmed functions to choose between the FlexBus and NFC signals on the pins. So for those signal the pin does not dynamically switch between the functions. It is fixed as a FlexBus or NFC pin based on whether you choose ALT5 or ALT6.

and if you only have one device connected with NFC interface, NFC_CE1_b can be used instead, but NFC_RB is a MUST option for NFC module, it is an input signal for this module to check if the flash is ready or busy.

Hope that helps,

Have a great day,
Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------