LPCSPFILib v0.06(Beta) available

[lpcware]

Content originally posted in LPCWare by NXP_Support on Fri Jun 27 09:42:55 MST 2014
New version (v0.06 Beta) of LPCSPIFI library available here.

[lpcware]

Content originally posted in LPCWare by schisanoa on Tue Sep 09 06:47:47 MST 2014
is there an example for LPC4088?

[lpcware]

Content originally posted in LPCWare by Dill on Thu Aug 21 02:30:05 MST 2014
thanks for the code. Unfortunately there is no driver for the family of QSPI we are using in lpcspifilib.
And there is also no driver for most of the devices listed in UM10430 - 4.3.6.4.1.
I've posted a new thread in lpcexpresso forum about this.

[lpcware]

Content originally posted in LPCWare by mch0 on Wed Aug 20 03:13:36 MST 2014
No problem.
This is the code "external" to the current spifi lib:

/* Register the correct family for the new device */
SPIFI_DEV_FAMILY_T *pFamilyHandle;
 pFamilyHandle = spifiRegisterFamily(SPIFI_REG_FAMILY_Spansion_2Byte_PStatus);

 /* Register the new device within the family */
 {
 static const SPIFI_DEV_PDATA_T pData =
 {
             "S25FL064P",
 {{0x01, 0x02, 0x16}, 0, {0}},/* JEDEC ID, extCount, ext data  */
 128,/* # of blocks */
 0x10000,/* block size */
 0,    /* # of sub-blocks  32 (This device only has sub-block erase in first/last 2 blocks) */
 0,    /* sub-block size  0x1000 */
 0x100,/* page size */
 32768,/* max single read bytes */
 40000000,/* max clock rate in Hz */
 (SPIFI_CAP_QUAD | SPIFI_CAP_FULLLOCK | SPIFI_CAP_NOBLOCK)/* capabilitites */
 };
 static SPIFI_DEV_DATA_T data;

 data.pDevData = &pData;
  spifiDevRegister(pFamilyHandle, &data);
 }

Within the spifilib in file spifilib_dev_common.c

you have to change the return parameter of the function

SPIFI_DEV_FAMILY_T *spifiRegisterFamily(SPIFI_DEV_FAMILY_T *(*regFx)(void))

/* Nothing to do here yet */
return pFam;
//mch return SPIFI_ERR_NONE;

That's all for now, the library detects the new device.

I am still not happy with some parameters, e.g. "max single read bytes". It is set to 32768 because for now I just adapted from the 32M device present. In reality the device does not have such a restriction.
But what is worse, when you try to issue a read command with 32768 Bytes the library fails again. I think it is a HW issue, because the SPIFI controller has  a length field for data read and it is 14 bits. This will allow for 16383 bytes with a single command at most.

[h2]Update:[/h2]

The library code for reading is indeed broken, as it does not check the length of the DATALEN field.
If you specify a length > 16383 then anything may happen. Other bits of the CMD-reg may get set, e.g. POLL. The result is likely to be a hard fault or an indefinite loop.

I can imagine more than one way to fix this.
For example, the read function could issue multiple read commands, it could return an error or during registering a device the max. length could be checked and an error could be reported.
This is a design decision and NXP should decide how to fix this.

As long as you don't try to read more than 16383 bytes there seems to be no further problem.

Mike


Best regards,

Mike

[lpcware]

Content originally posted in LPCWare by Dill on Tue Aug 19 11:53:14 MST 2014

very interesting. I've tried this yesterday and had the same issue, but didn't look into it.
I'd really like to see your fix for registering own devices.

[lpcware]

Content originally posted in LPCWare by mch0 on Tue Aug 19 11:16:03 MST 2014
Hi Dill,

thanks for the pointer, found the code you referenced!
First of all it indeed uses the new API, much better to have a reference now.
Second observation:
The library code is still broken, but the bug is not triggered by the test code.
Reason:
I had to register a new device (S25FL064P), the test code does not register any device besides the "built in" devices. Since I decided to keep my add-ons clear from the supplied library to avoid any overwrite when the next SPIFI lib arrives, I had to use the return parameter of the register-family function.
Well, that's where (one) bug is in V 0.6.
The test code never uses the return parameter ...

Anyway, since I'm now more confident that the files are basically usable I started some fixing.
At least I the library now correctly registers and detects my device :)

Thanks,

Mike

[lpcware]

Content originally posted in LPCWare by Dill on Tue Aug 19 10:13:53 MST 2014
yes, the code in the chm is outdated.

But there is some code in lpcopen that may help:

applications\lpc18xx_43xx\examples\misc\spifilib_tst
software\lpcspifilib\test

just link those files together and it runs.

[lpcware]

Content originally posted in LPCWare by mch0 on Tue Aug 19 08:51:56 MST 2014
Hi,

has the library really been tested with the files uploaded?
I can't believe it. I am keen to use such a library as my board contains a device of a supported family and the board already works so far.

But I can't get even past the first steps, e.g. registering a device. As far as I can see the example in the documentaion does not match the current version and even within the source there seem to be obvious errors.

These are my observations so far:

1. The " LPCSPIFILIB library use model" both in the PDF and the HTML doc refers to some previous version.

Examples:

a)  spifiInit() now has two parameters, but is called with one only in the use case.

b)  pFamilyHandle = spifiRegisterFamily(SPIFI_REG_FAMILY_SpansionS25FLP);
The parameter SPIFI_REG_FAMILY_SpansionS25FLP is marked as deprecated already (but works). Not convincing, though.
The function called (spifiRegisterFamily()) in spifilib_dev_common.c should return a pointer to the device family linked list but actually returns the status SPIFI_ERR_NONE.

This breaks the code, as the caller never gets the pointer.
I have stopped here, since I feel that either I'm completely off track or the supplied sources are severely mixed up. I could have started "fixing" the code, but since nothing seems to match I feel there is something severely mixed up and I better ask what gives?

Best regards,

Mike