VF6xxx NFC (NAND) module clocking

[billpringlemeir]

Section 31.4.5 Fast Flash Configuration for EDO has the following,

The NFC clock must be configured fast enough (usually > 33 MHz) according to the data sheet of flash devices.

On the IMX25, there are various timing diagrams which show how the NAND clock affect the timing.  Originally, the NFC_CLK (from Chapter 10) was 133MHz with the main line Linux.  I set this to 66MHz and the normal mode starts to function in EDO mode on the Tower board.  However, when I turn on the ECC code it fails.  I set the clock to 33Mhz and it is functioning.  9.12 Maximum Frequencies Supported has a maximum clocking of 80Mhz for the module.  What kind of clock ranges does the module accept and are there timing diagrams so we can run a timing budget with our NAND chip selection and PCB traces?

19.4.3 Clocks at Boot Time has some timings that the boot code sets, but it never has the ECC enabled.  Clocks are 30.85 (Normal Frequency) and 45.25 (Fast Frequency).  It seems odd that all of the MTD tests pass without ECC and a 66MHz clock, but they fail with ECC enabled.  The raw signals to the flash chip should be un-altered by the ECC; but I maybe running the NAND chip out of spec; how do I know?  Is the clocking different when the module ECC is enabled?

In my case, I have a software ECC (Hamming, much like boot code) and all checks pass.  There are other CRC32 data validations and no data or filesystem corruptions are observed with no hardware ECC and a 66MHz NFC clock.  However, as soon as the hardware ECC is enabled, usually the 2nd 16bit value is corrupted unless the clock is change to ~33Mhz.

[alejandrolozan1]

Hi karinavalencia,

Bill is still waiting for Israel answers. He just wants to know that clocking the NFC at 33Mhz is guaranteed safe all parts/ranges.

I wonder if someone else can provide the answer Israel was about to get from R&D?

Regards,

Alejandroe

[jiri-b36968]

vilemzavodny-b50857 will look at it.

/Jiri

[alejandrolozan1]

Hi vilemzavodny-b50857,

Sorry to bother you, I wonder if you have a chace to take a look at this discussion?

Thanks a lot ,

Alejandro

[VilemZ · Accepted solution]

Hi Alejandro,

I'm sorry for late answer. I have sent tyour question to some people, who can know it. But i get only this answer:

Is Customer asking that NFC at 33MHz will work fine, then the answer is yes.

Best Regards

Vilem

[alejandrolozan1]

Thanks Vilem ,

billpringlemeir just wanted to double check becuase we noticed a few problems when setting the NFC clock above 33MHz.

Bill, I wonder if there is some other information you need?

Best Regards,

Alejandro

[billpringlemeir]

Thanks, Alejandro/Vilem.  This is what I wanted to know.  There seems to be a difference between the hardware ECC and non-hardware ECC in the maximum clock rate (and the documentation is not consistent).

[falstaff]

Hi,

I can confirm this issue. My Platform Clock is 166MHz.

Register	Address	Errors	Working
CCM_CSCDR2	0x4006B018	0x30114210	0x30114220
CCM_CSCDR3	0x4006B01C	0x00083F1F	0x00083F1F

With a clock of 166/4 => 41.5MHz, I've got issues on every page.

With a clock of 166/6 => 33.2MHz, I've got no issues at all.

Best Regards,

Stefan Agner

[israelpz]

Hi Bill,

After i ask Chris, our R&D Vybrid NFC expert, He told us the NFC from Vybrid is based MPC51xx processor which his max clock is 40 Mhz.

He also told us the NFC clock is restricted by the PAD delay. He need to confirm the PAD timing requirement in Vybrid.

Maybe the limitation in Vybrid is below than 60 Mhz.

Regards,

-Israel.

[billpringlemeir]

Any news?

[alejandrolozan1]

Hi,

I tried with the MQX example with frequencies of 33MHz and 26.4MHz. It worked with no problems.

But at 44MHz if failed. You mentioned "Maybe the limitation in Vybrid is below than 60 Mhz." but how can we be sure of this?

Best Regards,

Alejandro

[billpringlemeir]

But at 44MHz if failed. You mentioned "Maybe the limitation in Vybrid is below than 60 Mhz." but how can we be sure of this?

See Stefan's post below.  I have also tried the Hardware ECC at other rates and it fails.  33Mhz seems to be the highest clocking that works empirically (Ie, black box or "try it out and see what happens" type of logic).

I believe there are multiple issues.  Chris (R&D Vybrid NFC expert) has more knowledge than I do.  All I can say is what does/doesn't work and refer to the existing Freescale documentation.  The Vybrid documentation currently  says a maximum clock input of 80MHz.  This is the clock to the NFC module itself.  What the rates are on pins, is derived from the NFC input clock; I guess it is synchronous logic and every N clocks (and fractions) some NFC pin will toggle.  I also looked a the Vybrid Electrical documentation; here there is also an error which wasn't fixed in the revision that happened since I reported this.  It is useful to verify NAND parts with controller logic.  The Vybrid Electrical documentation has some 'half-clock' notation that is only supported on another SOC; mainly this was just a distraction in finding out what is permitted.

However, the two things I have measured and many others have confirmed.

1. Hardware ECC fails above 33MHz.
2. Software ECC can work to 60MHz.

Ie, it seems that the Hardware ECC logic within the Vybrid controller has a lower clocking rate than just the PIN slew rates, etc.  The 33MHz rate is quite fine for our application and gives good performance when configured at this rate.  Also the hardware ECC significantly reduces CPU load and gives better error correction than standard software ECC.  The only issue I have, is it factory approved to run the Hardware ECC at this rate?  Or will there be some temperature/voltage/correction parameters/etc where the Hardware ECC may fail at 33MHz NFC input clocking?  Especially, the 'FAST FLASH' (or EDO) parameter seems to be needed at 33MHz for the Micron NAND. It would also be very nice to have correct documentation for the other values.

This post on Vybrid DMA also has some information on limiting factors for the NFC.  Clocking far above 33MHz is probably not beneficial as getting data from the M4/A5 to the NFC SRAM has these limitations.  The Vybrid NFC is getting about 1/2 the theoretical bandwidth (data sheet) for the Micron flash.  It is very respectable.  Is it safe?  I have had problems with other products when a die shrink of one chip exposed limitation in the controller on the CPU/SOC.  So we had a solution that worked until the memory vendor changed the process (but remained with-in their spec) and we had to reconfigure/slow down the CPU/SOC memory controller to accommodate the die shrink.  Production is not happy with development in cases like this.

[billpringlemeir]

The NFC seems to operate fine at 60MHz with no hardware ECC.  The hardware ECC fails above even 37.5MHz, I believe.  Also the pattern of the error with the 2nd 16 bits always failing seems to indicate that the correction went wrong quite early.  The rest of the buffer is fine except the 2nd 16bits and the ECC status flag is set. So, there seems to be some issue with the Hardware ECC; or it is at least more pronounced.  It could be true that neither of them should run at more than 40Mhz, but this contradicts most of the documentation.

19.4.3 Clocks at Boot Time has some timings that the boot code sets, but it never has the ECC enabled.  Clocks are 30.85 (Normal Frequency) and 45.25 (Fast Frequency).

and

9.12 Maximum Frequencies Supported has a maximum clocking of 80Mhz for the module.

I was pulled off on to something else, and then pulled off to something else.  I hope to have time to return to this to provide an MQX example as per SR 1-1270853186.  I am working on different issues for our customers and trying to not be a road block/hot path to the rest of my team in regards to other issues...

[billpringlemeir]

Section 3.7.6.2 NAND Flash Controller (NFC) Timing of IMX25CEC.pdf has the kind of timing diagrams I would expect/like so that we can know what kind of signalling the NAND flash chip can expect.  The IMX25 is a synchronously clocked controller.  Using the same Micron series with 8-bit 256MB version,

The Linux MTD test modules provide a means to measure flash performance.

NFC clock	T (nS)	Div	Write (MB/s)	Read (MB/s)	Erase (MB/s)
22MHz	45	/6	3.6	5.2	148
33MHz	30	/4	4.2	6.9	154
44MHz	22	/3	4.6	7.7	154

These values on an IMX25 (especially @44MHz) are double the current Vybrid speeds.  I have re-written the fsl_nfc.c driver and am trying to prepare it for the mainline Linux.  However, the hardware ECC doesn't not seem to work above speeds of 33Mhz with EDO enabled on the Vybrid.  Why?  I suspect that the hardware ECC is asynchronous and if we read too fast, it can not handle the data rate.  Oddly, the faster clocking does not seem to increase the data rate much/at all for the Vybrid NFC controller.

[billpringlemeir]

At least part of the performance issue is due to the Linux driver structure; at least for the write side.  I am not sure why the read performance is so slow for the Vybrid controller.  Also, I still don't understand why the hardware ECC fails with faster clock rates.  Finally, it is not entirely clear what kind of signalling the NFC will generate.  Maybe I have to solder a bunch of fly wires...

[billpringlemeir]

Now, I am smoking the IMX25 [memcpy() vs memcpy_fromio()],

mtd_speedtest: MTD device: 1
mtd_speedtest: MTD device size 8388608, eraseblock size 131072, page size 2048, count of eraseblocks 64, pages per eraseblock 64, OOB size 64
mtd_test: scanning for bad eraseblocks
mtd_test: scanned 64 eraseblocks, 0 are bad
mtd_speedtest: testing eraseblock write speed
mtd_speedtest: eraseblock write speed is 4284 KiB/s
mtd_speedtest: testing eraseblock read speed
mtd_speedtest: eraseblock read speed is 16286 KiB/s
mtd_speedtest: testing page write speed
mtd_speedtest: page write speed is 3560 KiB/s
mtd_speedtest: testing page read speed
mtd_speedtest: page read speed is 15937 KiB/s
mtd_speedtest: testing 2 page write speed
mtd_speedtest: 2 page write speed is 3893 KiB/s
mtd_speedtest: testing 2 page read speed
mtd_speedtest: 2 page read speed is 16125 KiB/s
mtd_speedtest: Testing erase speed
mtd_speedtest: erase speed is 132129 KiB/s
mtd_speedtest: Testing 2x multi-block erase speed
mtd_speedtest: 2x multi-block erase speed is 234057 KiB/s
mtd_speedtest: Testing 4x multi-block erase speed
mtd_speedtest: 4x multi-block erase speed is 248242 KiB/s
mtd_speedtest: Testing 8x multi-block erase speed
mtd_speedtest: 8x multi-block erase speed is 256000 KiB/s

The buffering must be re-written to improve the write speed; it should be about 8MB/s. However, I still want to know why the ECC controller fails above 33MHz.

[timesyssupport]

Hello Bill,

Thank you for your detailed analysis of this issue. I have added this as a bug in our internal issue tracking for the Linux 3.0 kernel for Vybrid. I do not have an ETA on a fix for this, as our development resources are focused on updating to a later version of the kernel for Vybrid. If this is a time sensitive issue for you, I would recommend escalating with Timesys as a services project.

Thanks,

Timesys Support

[billpringlemeir]

I am not sure what the issue you have filed is?  Your driver is slow?  I have attached patches for the 3.12-3.14 series that allow the Vybrid-NFC device to be used; It is GPL and your developers are free to use it.  I am still working on minor issues before I try to submit it.  The 'devm' and 'of' (open firmware/device tree) stuff would need to be removed to back-port to the 3.0 TimeSys series.  Also, the 'FAST_FLASH' should not be set if the NFC clock remains under ~30Mhz as the TimeSys U-boot does.  My original question was related to how the NFC clock input affects the module.  If the clock is above 33MHz, the hardware ECC begins to fail.  As the TimeSys code never runs above ~13MHz, you will never see this issue.  I don't think that TimeSys can answer this question.  This needs to be answered by Freescale or have I missed something in your reply?

[timesyssupport]

Hello Bill,

Thanks for attaching the patches. I filed the issue as that the ECC controller fails when the NFC clock is set over 33MHz. This may not be a driver issue, in which case Freescale would be better suited to assist with this issue. To confirm, you see the same issue when using your patches with mainline Linux, correct?

Thanks,

Timesys Support

[billpringlemeir]

I can only see this issue with the main-line driver above; more over only the mainline has the infra-structure to set the input clock to the NFC.  I guess if you edit the 'u-boot' source to change the NFC clock, you would see the issue with the TimeSys 3.0 driver; but I have not tried this.  The way the 'u-boot' and 'Linux' combination is setup with TimeSys, there is no way to clock the NFC above ~13MHz unless the source is modified.  With the mainline driver I have above, altering 'vf610-twr.dts' nfc '<clock>' line, you can change the frequency in divisors of 133Mhz (66, 44, 33, 26, 22, 19, 16, etc).  To verify with the TimeSys driver, the u-boot's CONFIG_SYS_CLKCTRL_CSCDR2 and CONFIG_SYS_CLKCTRL_CSCDR3 can change to alter the divisor and the 'FAST_FLASH' should be enabled (EDO flash mode).  The software ECC should work at 66MHz and 44Mhz, but the hardware ECC would fail (as per my observations).  I have dumped the buffers and the 2nd word is corrupt always.  I think that the ECC controller goes crazy with it's 'correction' if it is clocked above 33MHz, which is a magic number for the 'FAST_FLASH' to work.  Clocking above 33Mhz does not significantly improve read/write/erase performance as the controller make NFC access CPU bound.  However, below 33MHz, the time to move data from the flash starts to be more significant.  tR_ECC is typical 45uS, max 70 uS for the Micron flash (move data from NAND cell to NAND buffer); during this time the NFC is waiting for READY/BUSY.  The interface timing is ~16nS*1k -> 16uS (the minimum time for the NFC to act during a page read).   This is the time related to NFC clock input; but I don't know how.  It seems that 33MHz gives a read speed of ~15MB/s and 66MHz gives a read speed of 16.6MB/s.  The Hardware ECC @33MHz gives 16.2MB/s as in the numbers above; it is in-between as the software doesn't run the ECC, but the interface time runs slower (the NFC moving data from flash to buffers time increased).  If you could confirm the hardware ECC busts above 33MHz, that would help.  If I confirm, can we get someone from Freescale to answer/act or should I open a service request with Freescale or something?

Also things may work as in HardwareECC@33MHz; but that doesn't mean they are right.  I don't want the code to fail on one out of every 1000 units, especially on a hot day in some dirty location that I have to visit to diagnose the issue.  I would like some official confirmation on the timing for the chip.  Usually you must do a timing budget for the system, which is the flash chip, the flash controller and the PCB inter-connect.  Each new Vybrid design using NAND flash should have the information on the controller so an appropriate clock can be picked (no matter what software is used).  There really is no timing documentation on this NFC controller?   The same controller seems to be used for the MPC5125 (PowerPC) and the MCF54418 (ColdFire) SOCs.  Is there an NDA or public timing diagram for these SOC and the NFC in those implementations?  I think the Hardware ECC failing above 33MHz is an errata, but only a system designer could say if it may reliably work at 33MHz under different voltage/temperatures.  Or maybe I have set something up wrong; but if this is the case, it is most likely related to timing which I have no information on.

EDIT: The timing is available in Vybrid Fact sheet section 9.5.2.  This was the electrical/timing data that I wanted.  Now section 9.10.4 NFC clocking of the software user manual makes no sense.  There is no mention of high/low time there.  The clock inversion parameter makes more sense with the fact sheet timing.  However, this additional information doesn't explain the Hardware ECC failure above 33MHz.

2nd EDIT: Apparently the Vybrid Fact sheet is a copy of the Kinetis parts? See: MQX and Kinetis.  Also the MK70FN1M0VMJ12 data sheet, section 6.4.3. which is the same as the Vybrid document. This part seems to have a SIM_CLKDIV4; probably the Vybrid supplies tH/tL in a different way?  So I still do not know of any definitive answer on the Vybrid timing.  I think part of the story is in the fact sheet timing.

3rd Edit: I have open Service Request SR 1-1262845281.  This confirms that the electrical data sheet does not have the complete information.  Ie, the SIM_CLKDIV4 register doesn't exist on the Vybrid and there is some other timing source to the NFC controller; probably 9.10.4, but is the clock ever asymmetric.  Ie,  Is there still GLUE between these?  Or is NFC clock feed direct, which makes the NFC_CLK_INV bit in CCM_CSCDR2[14] rather confusing unless there is some phase relation.  I believe the MQX driver divides the platform clock by 5 for a 26MHz source and it does not set FASTFLASH, which also indicates a clocking under 33MHz.  The MQX driver does enable hw-ecc by default.

[timesyssupport]

Hello Bill,

In an attempt to reproduce this issue with the Timesys BSP, in u-boot 2011.12, I set CONFIG_SYS_CLKCTRL_CSCDR2 to 0x30114210 (for a total nfc clock divide of 4, leaving the nfc clock over 33MHz).

In Linux 3.0, I removed the #if block around the FAST_FLASH comment to enable EDO mode, and set CONFIG_MTD_NAND_FSL_NFC_SWECC=n in the kernel configuration (so hardware ecc is used). I was not successful in seeing any problems - the kernel loaded successfully, and I was also able to mount a jffs2 image as the root filesystem. Was there anything else you would like us to try under these conditions?

Thanks,

Timesys Support