Spifi library problem: reading from invalid address

[lpcware]

Content originally posted in LPCWare by hlsa on Tue Sep 03 22:27:04 MST 2013
Since I have not received an answer regarding a spifi problem in the peripherals forum (see http://www.lpcware.com/content/forum/spifi-library-non-keil-development), I will give it another try here.

The problem is quite simple: the SPIFI-library does not work.


Here is my code:
void FvSpifiInit(void)
{
int32_t ret = 0;

LPC_SCU->SFSP3_3 = SSP_IO | 3; /* P3_3: SPIFI_SCLK */
LPC_SCU->SFSP3_4 = SSP_IO | 3; /* P3_4: SPIFI_IO3 */
LPC_SCU->SFSP3_5 = SSP_IO | 3; /* P3_5: SPIFI_IO2 */
LPC_SCU->SFSP3_6 = SSP_IO | 3; /* P3_6: SPIFI_IO1 */
LPC_SCU->SFSP3_7 = SSP_IO | 3; /* P3_7: SPIFI_IO0 */
LPC_SCU->SFSP3_8 = SSP_IO | 3; /* P3_8: SPIFI_/CS */

/* Enable clock source for SPIFI */
LPC_CGU->BASE_SPIFI_CLK = 1<<24 | 1<<11; /* clock source IRC 12 MHz */

ret = pSpifi->spifi_init(&obj, 3, S_RCVCLK | S_FULLCLK, 12);
}

pSpifi points correctly to spifi_table, which is linked into my program code (0x1a035198). The spifi functions from the library are also correctly linked into the program (e.g. spifi_init at 0x1a01309c).

During linking, I get the following warning:
ld.exe: warning: C:\T\IPD10G2\M4\Bsp\Cmsis\spifi_drv_M4.lib(spifi_rom_api.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail

Running the program ends in an exception.
I debugged the assembler code of the spifi library: in the init function a ldr-Instruction loads data from 0x29004018 (see screenshot), which is obviously an invalid address.

I use the library which is mentioned above (file size: 35468 bytes). My controller is a LPC4357.

What's going wrong?

Best regards,
Holger

[lpcware]

Content originally posted in LPCWare by bavarian on Wed Sep 11 04:44:00 MST 2013
Hello Holger,

GCC assumes that wchar_t is a 4-bytes type by default. ARMCC assumes it is a 2-bytes type by default.

This means that creating a library with ARMCC and use it in GCC (and also vice versa) creates a warning, and in case of the SPIFI lib even a runtime error.
There are options in both toolsets to force usage of 4-bytes and 2-bytes types, but in fact the problem goes a little bit deeper than that.

In NXP we currently work on a solution of this conflict for the Cortex-M3/M4 SPIFI libs.
We will keep you updated on this.

There is an LPCXpresso example which deals with the SPIFI but not using the library, maybe it can help you:

http://www.lpcware.com/content/forum/spifi-errata-and-part-version-information#comment-1023028


Best regards,
Bernhard.