AnsweredAssumed Answered

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

Question asked by Cory Heuschkel on Aug 24, 2016

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

Outcomes