FAQs
English (US) 日本語 | Japanese 中文 | Chinese (Simplified)

Running from SPI flash?

cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Running from SPI flash?

‎06-15-2016 11:16 AM
3,127 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by chuckp on Tue May 22 12:57:31 MST 2012
Can anyone suggest how to build a project so that some functions execute from SPI flash, while others are loaded into RAM?

I am working with an LPC1850.  I have a Hitex A4 board, and I have IAR tools.  I'd like to find an example of a project putting some code in RAM and running other code from SPI flash.  I've looked through the various examples.  I see the SPIFI example.  When I run that code, I find that the pSpifi->spifi_program() function in the ROM table is zero.  When I try to link in the spifi library provided with the CMSIS package, the program fails to start.  But this isn't obviously about running code from SPIFI.

I see the "bootfast" example from the CMSIS package, but that has only a Kiel setup, and I'm also not convinced it is about running code from flash.

I also see that there is an image manager tool that may be involved.
Labels (1)
Labels
0 Kudos
Reply
9 Replies

‎06-15-2016 11:16 AM
2,864 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mdittrich on Thu Oct 25 13:06:55 MST 2012
Don't know if you are still having issues, but I found adding "--no-wchar-size-warning" while linking shut GCC up about the 2 vs 4 whar_t's.

I only had one "Conflicting CPU architecture 13/0" message from falcon_details.o, and defining a pullMISO() got rid of that.

One GCC I had needed a __aeabi_memcpy4() defined, a wrapper around plain-ole-memcpy seemed to work.

It certainly would be nice to be able to recompile that library...

MD
0 Kudos
Reply

‎06-15-2016 11:16 AM
2,864 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by bunrockter on Tue Oct 16 20:45:21 MST 2012
I actually downloaded the M4 lib and I still get the same errors.


    "C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld" -X -ereset_handler --omagic -defsym=__do_debug_operation=__do_debug_operation_mempoll -u__do_debug_operation_mempoll -defsym=__vfprintf=__vfprintf_int -u__vfprintf_int -defsym=__vfscanf=__vfscanf_int -u__vfscanf_int --fatal-warnings -EL --gc-sections "-TC:/Users/Bun/Documents/CrossWorks Projects/Sun_meter/THUMB Debug/Sun_Meter.ld" -Map "THUMB Debug/Sun_Meter.map" -u_vectors -o "THUMB Debug/Sun_Meter.elf" --start-group "THUMB Debug/I2cController.o" "THUMB Debug/LcdController.o" "THUMB Debug/lwIPMgr.o" "THUMB Debug/SdController.o" "THUMB Debug/SelfTest.o" "THUMB Debug/SoftwareUpdater.o" "THUMB Debug/Valve.o" "THUMB Debug/ZoneController.o" "THUMB Debug/I2cReadEvt.o" "THUMB Debug/I2cWriteEvt.o" "THUMB Debug/GUI_X.o" "THUMB Debug/GUIConf.o" "THUMB Debug/LCDConf.o" "THUMB Debug/SIMConf.o" "THUMB Debug/eth_driver.o" "THUMB Debug/bsp.o" "THUMB Debug/EmcDriver.o" "THUMB Debug/gpio.o" "THUMB Debug/isr.o" "THUMB Debug/LcdDriver.o" "THUMB Debug/lwip.o" "THUMB Debug/Main.o" "THUMB Debug/mini_cpp.o" "THUMB Debug/PinConfig.o" "THUMB Debug/RtcDriver.o" "THUMB Debug/SdDriver.o" "THUMB Debug/sntp.o" "THUMB Debug/spiDrive.o" "THUMB Debug/spifiDriver.o" "THUMB Debug/thumb_crt0.o" "THUMB Debug/Hitex_LPC4350_ctl_board.o" "THUMB Debug/LPC4300_ctl.o" "THUMB Debug/LPC4300_Startup.o" ../Libraries/Cortex-m4/Lib/qpLibDbg.a Lib/libemWin_516_LPCXpresso423_M4_LE_Redlib.a "C:/Users/Bun/Documents/CrossWorks Projects/Sun_meter\\\\Lib\\\\Drivers_lib_spifi_drv_M4.lib" "C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/lib/libm_v7em_fpv4_sp_d16_t_le_eabi.a" "C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/lib/libc_v7em_fpv4_sp_d16_t_le_eabi.a" "C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/lib/libcpp_v7em_fpv4_sp_d16_t_le_eabi.a" "C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/lib/libdebugio_v7em_fpv4_sp_d16_t_le_eabi.a" "C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/lib/libc_debugio_impl_v7em_fpv4_sp_d16_t_le_eabi.a" "C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/lib/libc_user_libc_v7em_fpv4_sp_d16_t_le_eabi.a" --end-group
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: warning: C:/Users/Bun/Documents/CrossWorks Projects/Sun_meter\\\\Lib\\\\Drivers_lib_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
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: warning: C:/Users/Bun/Documents/CrossWorks Projects/Sun_meter\\\\Lib\\\\Drivers_lib_spifi_drv_M4.lib(amic.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
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: warning: C:/Users/Bun/Documents/CrossWorks Projects/Sun_meter\\\\Lib\\\\Drivers_lib_spifi_drv_M4.lib(atmel.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
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: warning: C:/Users/Bun/Documents/CrossWorks Projects/Sun_meter\\\\Lib\\\\Drivers_lib_spifi_drv_M4.lib(chi.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
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: warning: C:/Users/Bun/Documents/CrossWorks Projects/Sun_meter\\\\Lib\\\\Drivers_lib_spifi_drv_M4.lib(eon.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
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: warning: C:/Users/Bun/Documents/CrossWorks Projects/Sun_meter\\\\Lib\\\\Drivers_lib_spifi_drv_M4.lib(esmt.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
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: warning: C:/Users/Bun/Documents/CrossWorks Projects/Sun_meter\\\\Lib\\\\Drivers_lib_spifi_drv_M4.lib(giga.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
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: warning: C:/Users/Bun/Documents/CrossWorks Projects/Sun_meter\\\\Lib\\\\Drivers_lib_spifi_drv_M4.lib(macronix.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
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: warning: C:/Users/Bun/Documents/CrossWorks Projects/Sun_meter\\\\Lib\\\\Drivers_lib_spifi_drv_M4.lib(numonyx.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
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: warning: C:/Users/Bun/Documents/CrossWorks Projects/Sun_meter\\\\Lib\\\\Drivers_lib_spifi_drv_M4.lib(spansion.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
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: warning: C:/Users/Bun/Documents/CrossWorks Projects/Sun_meter\\\\Lib\\\\Drivers_lib_spifi_drv_M4.lib(sst.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
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: warning: C:/Users/Bun/Documents/CrossWorks Projects/Sun_meter\\\\Lib\\\\Drivers_lib_spifi_drv_M4.lib(winbond.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
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: error: C:/Users/Bun/Documents/CrossWorks Projects/Sun_meter\\\\Lib\\\\Drivers_lib_spifi_drv_M4.lib(falcon_details.o): Conflicting CPU architectures 13/0
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: error: C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/lib/libc_v7em_fpv4_sp_d16_t_le_eabi.a(libc2_asm.o): Unknown CPU architecture
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: error: C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/lib/libc_v7em_fpv4_sp_d16_t_le_eabi.a(__vfscanf_int.o): Unknown CPU architecture
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: error: C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/lib/libcpp_v7em_fpv4_sp_d16_t_le_eabi.a(__aeabi_atexit.o): Unknown CPU architecture
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: error: C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/lib/libc_debugio_impl_v7em_fpv4_sp_d16_t_le_eabi.a(libc_debugio_impl_asm.o): Unknown CPU architecture
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: error: C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/lib/libm_v7em_fpv4_sp_d16_t_le_eabi.a(libm_asm.o): Unknown CPU architecture
    "C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/objcopy" "THUMB Debug/Sun_Meter.elf" "C:/Users/Bun/Documents/CrossWorks Projects/Sun_meter/THUMB Debug/Sun_Meter.hex" -Oihex
0 Kudos
Reply

‎06-15-2016 11:16 AM
2,864 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Daniel Widyanto on Mon Oct 15 20:18:05 MST 2012
The previous post links to LPC18xx library (ARM Cortex-M3), while your target is LPC43xx (ARM Cortex-M4). So the compiler complains that it's conflicting CPU architecture

The correct link should be http://sw.lpcware.com/index.php?p=lpc43xx.git&a=tree&h=69968f319db2e5ebe9e5fe564888bb924b1c0b93&hb=7...

0 Kudos
Reply

‎06-15-2016 11:16 AM
2,864 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by bunrockter on Sat Oct 13 00:39:31 MST 2012
I am trying to get SPIFI up and running on a LPC4350. I was able to init the device when I was using the ROM driver, but then realized that I would need a new driver as mentioned up above. However when I link in the lib file i get errors about hidden symbols & CPU architecture problems. I don't have uv, so I can't open up the project and check for any extra settings I might be missing. Did anyone else run in to this issue?

thanks,

Bun

Here is the output of the compiler:

    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: warning: C:/Users/Bun/Documents/CrossWorks Projects/project/Lib/Drivers_lib_spifi_drv_M4.lib(winbond.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
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: error: C:/Users/Bun/Documents/CrossWorks Projects/project/Lib/Drivers_lib_spifi_drv_M4.lib(falcon_details.o): Conflicting CPU architectures 13/0
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: error: C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/lib/libc_v7em_fpv4_sp_d16_t_le_eabi.a(libc2_asm.o): Unknown CPU architecture
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: error: C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/lib/libc_v7em_fpv4_sp_d16_t_le_eabi.a(__vfscanf_int.o): Unknown CPU architecture
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: error: C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/lib/libcpp_v7em_fpv4_sp_d16_t_le_eabi.a(__aeabi_atexit.o): Unknown CPU architecture
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: error: C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/lib/libc_debugio_impl_v7em_fpv4_sp_d16_t_le_eabi.a(libc_debugio_impl_asm.o): Unknown CPU architecture
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: error: C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/lib/libm_v7em_fpv4_sp_d16_t_le_eabi.a(libm_asm.o): Unknown CPU architecture
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: THUMB Debug/project.elf section `.constdata' will not fit in region `UNPLACED_SECTIONS'
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: region `UNPLACED_SECTIONS' overflowed by 397 bytes
    C:/Users/Bun/Documents/CrossWorks Projects/project/Lib/Drivers_lib_spifi_drv_M4.lib(spifi_rom_api.o): In function `spifi_program':
    ..\spifi_rom_api.c:(.text+0xe9c): undefined reference to `__aeabi_memcpy4'
    C:/Users/Bun/Documents/CrossWorks Projects/project/Lib/Drivers_lib_spifi_drv_M4.lib(spifi_rom_api.o): In function `spifi_erase':
    ..\spifi_rom_api.c:(.text+0x10ec): undefined reference to `__aeabi_memcpy4'
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: THUMB Debug/project.elf: hidden symbol `__aeabi_memcpy4' isn't defined
    C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM 2.2/gcc/arm-unknown-eabi/bin/ld: final link failed: Bad value

0 Kudos
Reply

‎06-15-2016 11:16 AM
2,864 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by JAlvarez on Wed Aug 08 06:02:32 MST 2012
Hi, nxp21346.

Thanks for removing the incorrect documentation on the ROM SPIFI driver. It is important to note that the SPIFI flash driver is distributed with the PDL as a binary library (spifi_drv_PI.lib).

http://sw.lpcware.com/index.php?p=lpc18xx.git&a=tree&h=560ca02f0bffa624304dd62271f728b716ddb404&hb=2...

The SPIFI flash driver source code was deleted from the LPCWARE repository in Dec-2011.

http://sw.lpcware.com/index.php?p=lpc18xx.git&a=commit&h=2d75d75a54ae86295e268fbdc171e8c6d17d0f39

A binary driver is difficult to extend and imposes limitations for many embedded applications. For example, the Dec-2011 driver included 12 SPIFI vendor drivers. Since many designs only use one or two flash vendors, a developer can reduce the driver object size by eliminating other vendors. The linker can't optimize this since pointers to the base driver function for each vendor are part of the "mfgEnt" structure in spifi_rom_api.c so the vendor is determined at runtime by spifi_init(). A binary driver also makes it difficult to support other SPIFI flash components (limiting developers to the current ones), correct bugs in the driver, add features, etc.

Why was the SPIFI driver source removed from the repository? If NXP decided to remove the spifi_program() logic from the LPC43xx ROM, the SPIFI flash driver should be available in source code form. All other drivers in the PDL appear to be in source code form. What prevents NXP from distributing source code to the SPIFI flash driver?

Using a binary driver also creates a problem with source redistribution for many embedded projects. May OEMs require full source code of the firmware used on a design project. A binary library prevents this. The Dec-2011 source code didn't have any licensing limitations other than the restriction of use with NXP microcontrollers. Can the Dec-2011 source code in the second link above be redistributed with the BSP of hardware designs using NXP LPC18xx or LPC43xx microcontrollers? Will NXP disclose any SPIFI driver fixes implemented after Dec-2011?

In my opinion, the best solution would be making the SPIFI flash driver source code available again in the LPCWARE repository.
0 Kudos
Reply

‎06-15-2016 11:16 AM
2,864 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by nxp21346 on Thu Aug 02 12:24:54 MST 2012
Hi JAlvarez,

A SPIFI library (which has been tested in Keil, IAR, and LPCXpresso) is distributed with the PDL and used by the SPIFI examples. We have updated the library API documentation in the PDL so that it does not mention the presence of a ROM-based SPIFI driver since it isn't present in the ROM on the LPC43xx or LPC18xx parts shipping today. If we add the SPIFI library to the ROM, look for it to be mentioned in the part documentation (User's Manual, Data Sheet, Errata).

Thanks,
-NXP
0 Kudos
Reply

‎06-15-2016 11:16 AM
2,864 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by JAlvarez on Fri Jul 20 18:00:42 MST 2012
> the pSpifi->spifi_program() function in the ROM table is zero

The SPIFI driver on the LPC43xx ROM is not operational and should not be used. We found this out from NXP after spending several hours trying to use it for page writes. Officially it only supports booting from SPIFI. Unofficially, the spifi_init() and spifi_erase() APIs mostly work but spifi_program() is no longer in ROM. That is why you get a null pointer for spifi_program().

The SPIFI examples that use CMSIS appear to work. Yet if your application does not use CMSIS, this forces you to link to a large NXP-proprietary library just for the SPIFI page write functionality.

The misleading SPIFI_ROM_support.doc document is still on the LPC43xx and LPC18xx CMSIS downloads and repositories (Drivers/lib directory). Some examples still refer to a spifi_rom_api.h header that should never be used. Those documents and the header have been out over 6 months on an NXP production part. NXP needs to be more careful about documentation when they change their ROM code. Documentation errors lead to a lot of wasted time and effort.
0 Kudos
Reply

‎06-15-2016 11:16 AM
2,864 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by chuckp on Thu Jun 07 10:16:56 MST 2012
I now have it working.  The key missing piece seems to have been the definition of the __Setup function in the .mac file referenced in the .flash file and used for downloading.  Some of the examples of this file (for instance, in the 2012-04-17 CMSIS) have an empty __Setup function.  Others use the wrong address to enable the clock.  The function I am now using is below.
Of course you need to get all of the the other settings correct.  With luck I've made enough noise that these fixes will be incorporated in a release.

__Setup()
{
        /* set SPIFI clock */
        //LPC_CGU->BASE_SPIFI0_CLK = 1<<24 | 1<<11; /* IRC 12 MHz is good enough for us */
          __writeMemory32( 1<<24 | 1<<11, 0x40050070, "Memory");
        // As delivered, used 0x40051304, which was the wrong address.
       
        /* set up SPIFI I/O (undocumented bit 7 set as 1, Aug 2 2011) */
        //LPC_SCU->SFSP3_3 = 0xF3; /* high drive for SCLK */
        __writeMemory32( 0xF3, 0x4008618C, "Memory");

        /* IO pins */
        //LPC_SCU->SFSP3_4=LPC_SCU->SFSP3_5=LPC_SCU->SFSP3_6=LPC_SCU->SFSP3_7 = 0xD3;
        __writeMemory32( 0xD3, 0x40086190, "Memory");
        __writeMemory32( 0xD3, 0x40086194, "Memory");
        __writeMemory32( 0xD3, 0x40086198, "Memory");
        __writeMemory32( 0xD3, 0x4008619C, "Memory");

        //LPC_SCU->SFSP3_8 = 0x13; /* CS doesn't need feedback */
        __writeMemory32( 0x13, 0x400861A0, "Memory");
       
        // map SPIFI to shadow area at address 0
        __writeMemory32(0x14000000, 0x40043100, "Memory");
}
0 Kudos
Reply

‎06-15-2016 11:16 AM
2,864 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by chuckp on Fri May 25 12:43:32 MST 2012
I thought a reasonable first step might be to read and write the SPI flash.  I'm using the SPIFI example from the CMSIS package as my basis.  I can now use either the internal or external spifi code:

#if 1  // library version
    extern SPIFI_RTNS spifi_table;
    pSpifi = &spifi_table;
#else  /* on chip ROM version */
    pSpifi = *((SPIFI_RTNS **)SPIFI_ROM_PTR);
#endif

spifi_init returns OK.

    rc = pSpifi->spifi_init(&obj, 3, S_MINIMAL, 12);

I can read the spi flash.  I get all FF's, and I see the MISO pin moving on a scope.  I can see the SPIFIobj and SPIFI_RTNS structures.  With the on chip code, the program function is null.  It is not null with the library. So they are different.  From the SPIFIobj structure, mfger=0x01, devType =0x02, devID = 0x16.

But the erase command fails, returning 0x20005. 
            opers.dest = (char *)(obj.base);
            opers.length = 256; // obj.memSize;
            opers.scratch = NULL;
            opers.options = 0; // S_VERIFY_ERASE;
            /* Erase Device */
            rc = pSpifi->spifi_erase(&obj, &opers);

What is the meaning of the error code?  Any guesses what might be wrong?





0 Kudos
Reply