NFC_LDD limitations...

[bowerymarc]

The NFC_LDD component doesn't support more than one target (I'm assuming a target is a Chip Select?) and doesn't support partial pages.  Any idea when these might be implemented?

I'm putting this in a K20F120X, and wanted to have two NAND flashes off the two Nand CE's, and think it'll be handy to use 512B partial pages to map a filesystem onto the flash.

[Petr_H · Accepted solution]

Hi,

Yes, this is currently the limitation of the NFC_LDD component. I have passed your request to the development team to improve the component in the future releases. However, they currently don't have a plan for this change, so it may take some time to implement it.

best regards

Petr Hradsky

Processor Expert Support Team

[bowerymarc]

Which change are you referring to? Partial pages, or multiple chip selects?

[Petr_H]

In the near future there is no plan for supporting any of these. However, as I wrote, I have passed this to development team to consider this for implementing.

best regards

Petr Hradsky

Processor Expert Support Team

[bowerymarc]

Thanks for the reply Petr,

Please pass along to your team my disappointment that they feel it's OK to publish half-baked software components and leave it at that.  Where's is the old engineering pride of craftsmanship?

This is the second disappointing component I've come across in my short journey, the other being the SDHD component.

The whole point of "Processor Expert" is that the factory-provided components are highly optimized, to save development time for the 1000's of projects using the chips.  the NFC_LDD and SDHD_LDD component fail miserably at that task.

So Freescale has a piece of silicon which can not reasonably be used due to software component inadequacy.  Not a great sales plan for them.  I hope they take note. 

Freescale: why bother putting hardware support for multiple NAND flashes if you don't support it with software?  Why put a 4-bit wide SDHD controller capable of clocking at 50MHz with a screaming data path including DMA support if you don't support it with software?

Now I'm faced with having to learn how to develop PE components, reverse engineer the NFC_LDD component, clean it up, fix it, and test it.  Time spent better doing other things.  Multiply by how many 100's or 1000's of engineers faced with similar, and you can start to understand the impact of publishing substandard software components.

Sincerely,

Marc Lindahl

[vfilip]

Hello,

regarding SDHC_LDD - could you please be more specific what feature is missing in this component for you? I have discussed it with developers and I have got info that it is using internal ADMA2 for data transmission and it should be capable to operate on 50 MHz.

best regards

Vojtech Filip

Processor Expert Support Team

[bowerymarc]

Hi Vojtech,

A quick search of the boards here and you'll see that the performance of this component is dismal.  I've benchmarked it myself and it is unbelievably slow. 

Secondly, it only supports one bit interface to SDHC, even if you enable 2 or 4 bits in the components it doesn't actually use them.

Regards,
Marc

[LadislavVadkerti]

Hi Marc,

if you want to use 4 bit wide data transfers, you have to enable 4 bit data interface and then, after card initialization, you have to call the SetDataWidth method, if the card supports it. I also made some benchmarking and if you have an oscilloscope you would see, that the component is waiting for a card response most of the time. When you read blocks from a card, the access time is composed from an asynchronous part (which can be in tens of milliseconds - you can decode it from the CSR register - see the SD spec.) and synchronous part dependent on the transfer size.

Best regards,

Ladislav Vadkerti

[bowerymarc]

Hi Ladislave,

Please don't try to blame the SD card!  I've benchmarked the card on i.MX31 with small blocks at 30MB/s read, about 10MB/s write.

Obviously I'm setting the 4-bit mode in the PE component, and even traced through that it's supposedly being set in the SW.  But the benchmark result is exactly the same.  See these links:

SDHD and NAND flash speed benchmarks?

FatFs with Kinetis | MCU on Eclipse

If you have conducted benchmarks please post the code and your results.  Noone around here is getting any fast speeds from the component, maybe we're all missing something.