Erasing SPIFI data block causes hard fault after reset (can't run to main)

cancel
Showing results for 
Search instead for 
Did you mean: 

Erasing SPIFI data block causes hard fault after reset (can't run to main)

645 Views
Contributor I

I originally posted the following question (LPCLink-2) Trouble setting up SPIFI while running application from external Flash but got no response.  In short, I was able to overcome some barriers but am presented with another.  I can access SPIFI using spifilib now that the whole library has been relocated to RAM.  But after erasing the allocated data block, a reboot causes a hard fault somewhere deep in the IAR sys init (before main is even called).  Please see my attached HAL file for accessing SPIFI using spifilib.

 

System setup

LPCLink-2 (LPC4370 with Winbond W25Q80BV external Flash)

IAR EW for ARM v7.70.1

Segger J-Link V5.12g (J-Flash SPI utility)

XIP code from SPIFI with spifilib/HAL in RAM

 

I can successfully erase Flash.  I have verified this by reading the whole Flash chip using J-Flash SPI connected to the Flash part itself.  As you can see, data gets cleared as expected in a diff of the two Intel .hex files:

 

Text Compare
Produced: 8/24/2016 11:05:51 AM

 

Mode: Differences, Ignoring Unimportant
Left file: C:\temp\noerase.hex Right file: C:\temp\posterase.hex
:20000000C4AF10110100035501053501FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCB <> :20000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00
------------------------------------------------------------------------

 

Note that the addresses shown are in the extended address region which means the data starts at address 0x10000 on the W25Q80BV part.  This diff shows that the only difference in the two images before/after the erase is the allocated data section at 0x10000 on the Flash part which correlates to 0x14110000 in the 4370 memory map.

 

After erasing this data block, upon reboot I get a hard fault before main even runs.  It is impossible to debug since the BFAR/MMFAR point at the DCRDR.  I have verified my VTOR is getting set to 0x14000000 as expected.  This bug only occurs when erasing; if the erase code is removed and only the program call is left in, the data is programmed successfully (at least on cleared bytes) and the 4370 reboots and runs as expected.

 

Some questions regarding my bug are: why does erasing this section cause a hard fault?  Is there some way to figure out if any of the data sitting in these addresses is needed to boot from memory correctly?  

 

Other questions regarding general documentation: how is SPIFI used to load the application into RAM on boot (what code is ran to do so)?  How does SPIFI map the data addresses on the Flash part to the map on the processor?

 

Please see the attached HAL file I pulled from examples and the default SPIFI linker config I am using.  

 

Regards,

Cory Heuschkel

Original Attachment has been moved to: spifihal.c.zip

Original Attachment has been moved to: lpc18xx_43xx_spifi_heap.icf.zip

Labels (1)
0 Kudos
3 Replies

11 Views
Contributor I

Hi Ma Hui,

This is definitely the correct answer and I forgot to update this post after I fixed this last week.  I wanted to mention that the SPIFI memory addresses 0x14000000-0x140FFFFF map to the entire Flash region (0x00000-0xFFFFF) of the chip.  This was the base of my confusion with how the mapping occurred and how to set up SPIFI correctly.  

I know erasing and writing to addresses outside of the Flash-mapped region in the SPIFI addresses caused the interrupt vector table I had at 0x14000000-0x14000140 to erase, but I'm not exactly sure why.  

I am going to create a new post on how I was able to read and write data blocks to SPIFI while using it to XIP code so that the community can have some guidance. 

Regards,

Cory Heuschkel

 

0 Kudos

11 Views
Contributor I

See my post https://community.nxp.com/thread/433206  for more information on my solution.

0 Kudos

11 Views
NXP TechSupport
NXP TechSupport

Hi

First of all, sorry for the later reply.

I consulted the LPC product team about this issue, who suggested to modify the SPIFLASH_BASE_ADDRESS to 0x14000000.

Please using below definition in <spifihal.c> file:

#define SPIFLASH_BASE_ADDRESS (0x14000000)


Wish it helps.

Have a great day,
Ma Hui
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos