Running from SPIFI causes immediate hard fault

[lpcware]

Content originally posted in LPCWare by bunrockter on Wed Feb 13 00:13:07 MST 2013
I have have Hitex board (One of the newer ones). I am using crossworks, and can run my programs just fine from SRAM. but when I switch to running them from SPIFI, immediately upon breaking at the first instruction the faultmask register gets masked (it stays that way until I erase the SPIFI, and kill power). The code will continue to run, but interrupts wont fire since faults are masked.. If I clear the mask, the code immediately hard faults and the vector table bit is set in the hard fault status register. From what I can find in the ARM documentation this means that there was either a bus fault while accessing the vector table, or there was an offset error while accessing the vector table.

I even get this issue when running the example code supplied by crossworks. I have spoken with them, and they said it works just fine for them. Has anyone else run into this? The exact same code runs just fine in SRAM, but when I run from SPFI (well copy from SPIFI into RAM and then run actually) I fault every time. I have to Clear out the SPIFI and then cut power to the board before I can run from ram again, or I get the fault (perhaps the bit is sticky? A reset doesn't even do it)

Any suggestions would be greatly appreciated.

Thanks,

Bun

[lpcware]

Content originally posted in LPCWare by ArriaLive on Fri Aug 29 13:08:19 MST 2014
I figured it out.  See my other post here.

[lpcware]

Content originally posted in LPCWare by ArriaLive on Thu Aug 28 09:03:38 MST 2014
MC, thank you for your response!

I am aware that the flash memory space is mirrored, and I get the same values when I peek at the memory locations.  The M4MEMMAP is pointed to 0x80000000 which is at least fine for now.  I can change it to 0x14000000, and have done that, but it makes no difference.

Here's the problem:

1 - I read and XIP from flash, and can validate it.  I also read the SPIFI MEMCMD register to see what the value is.
2 - I send a reset (0x10) to STAT register, then wait for the reset to complete.  At this point the memory at 0x14000000 is unreadable (expected).
3 - I immediately put SPIFI back in memory mode with the same value that was in the MEMCMD before.

That's it.  After these simple steps, I can verify that SPIFI is in memory mode (MCINIT set to 1), I can peed at the memory at 0x14000000, but the content of the memory has completely changed--to 0s or all 0xCCCCCCCC.

My question is, where did my memory go?  Is there some register somewhere in the processor that is cleared when I do the reset?  What does the bootloader do to "set up" the SPIFI?  Do I need to do that again after the reset?  What are those steps?

Note that we are not using the boot pins in our design, but are using the boot_src in the OTP processor memory, currently set to 0b0010.  This works quite well for normal booting on its own, but maybe doesn't work for SPIFI init?

Also, note that I have been able to get the SPIFI out of memory mode without using the reset (by simply sending a different CMD (MBR, RDSTR1, etc.).  Following these commands, I can usually put SPIFI back into memory mode successfully.  That is my work around for now, but it is contrary to the documentation.

Thanks,
EdA

[lpcware]

Content originally posted in LPCWare by mc on Wed Aug 27 18:24:00 MST 2014
Hi bunrockter/ArriaLive,
The lower 64MB address space is mirrored at 0x14000000 and 0x80000000. SPIFI should be in memory mode to see the flash contents.

---

Quote:
What are the options for getting the flash addressable after a SPIFI reset?

---

Are you booting from SPIFI(Correct Boot jumper setting or source selection in boot source register)?

Boot from SPIFI will show you same code at 0x14000000 and 0x80000000 for 64MB size.

[lpcware]

Content originally posted in LPCWare by ArriaLive on Wed Aug 27 16:59:23 MST 2014

---

Quote: nxp21346
Sorry, I should have posted this sooner-
the SPIFI is unlike internal flash or some other types of memory, it does not come up by itself.
If you are debugging in a tool, typically you will have to program the SPIFI in order just to initialize it so the code will appear in memory. If you reset the part after programming it, then the SPIFI contents will disappear (the memory region won't show what is in the external serial flash) unless you have the boot jumpers set to boot from SPIFI, in which case the boot ROM will initialize it again.

-Dave @ NXP

---

Really?  With the LPC4330, we are using the OTP (boot_src) option to specify the boot from SPIFI option.  We are not using boot jumpers.  However, when I reset the SPIFI, the code disappears.  Shouldn't the boot jumpers and the boot_src provide the same functionality in initializing the SPIFI?  The (fig 14) flowchart would suggest so.

What are the options for getting the flash addressable after a SPIFI reset?

[edit]
Note that the M4MEMMAP == 0x80000000 both before and after the SPIFI reset.  Should that be 0x14000000?  The code seems to execute fine in flash prior to the SPIFI refresh with the PC clearly in the 0x14000000 range and M4MEMMAP == 0x80000000, but the flash still disappears after the SPIFI reset.  I also tried setting the M4MEMMAP to 0x14000000 with no change in the disappearing flash.

Thanks
EdA

[lpcware]

Content originally posted in LPCWare by bunrockter on Tue Feb 19 12:17:05 MST 2013
I had my boot jumpers configured as you suggested. I was getting the vector fetch hard fault with them set that way. I changed them as noted in my previous post and now I, don't get the hard fault, but I have to power down every time I want to run (with jtag)

I copy the vector table to x1000000 (sram), this is also the address that gets loaded into the vtors register (after the copy)

The M4MEMMAP starts out at x80000000 without me modifying it. Am I allowed to write x14000000 to it? Should I be doing this? I thought the boot rom read the jumpers and set it accordingly?

Thanks

[lpcware]

Content originally posted in LPCWare by nxp21346 on Mon Feb 18 15:36:11 MST 2013
The boot jumper settings for SPIFI boot on the Hitex board are:
BOOT1 = 1-2
BOOT2 = 2-3
BOOT3 = 2-3
BOOT4 = 2-3

Copying the vector table to 0x14000000 will cause a problem because that region is read-only (it is the SPIFI)

M4MEMMAP is used to set the memory that appears at 0x00000000. You should set it to 0x14000000 unless you need the extra aperture available at 0x80000000. (The boot ROM uses 0x80000000) You should set VTOR to point to your vector table whether that is 0x00000000 or 0x00000100 (wherever you have located it)

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/Ciheijba.html
Here is info on the VTOR register, some of the low bits are permanently set to 0. This is also true for the M4MEMMAP register.

Hope this helps,
-Dave @ NXP

[lpcware]

Content originally posted in LPCWare by bunrockter on Thu Feb 14 21:35:37 MST 2013
So then according to Appnote I had the jumpers right the first time, and I was getting the hard fault. So I guess the problem isn't really fixed?

I set boot 1=2-3  2=1-2 3=2-3 and 4 =2-3     and things started working?

The for the linker, the script sets the vectors to have a virtual Address at 0x14000000 (the fast dubuggable area of the SPFI memory map), and the startup script coppies the vector table to this location before updating the VTOR register.

Should the M4MEMMAP read 0x14000000 or 0x80000000?

[lpcware]

Content originally posted in LPCWare by nxp21346 on Thu Feb 14 11:33:07 MST 2013
Sorry, I should have posted this sooner-
the SPIFI is unlike internal flash or some other types of memory, it does not come up by itself.
If you are debugging in a tool, typically you will have to program the SPIFI in order just to initialize it so the code will appear in memory. If you reset the part after programming it, then the SPIFI contents will disappear (the memory region won't show what is in the external serial flash) unless you have the boot jumpers set to boot from SPIFI, in which case the boot ROM will initialize it again.

-Dave @ NXP

[lpcware]

Content originally posted in LPCWare by nxp21346 on Thu Feb 14 11:26:37 MST 2013
Check out this app note:
http://www.lpcware.com/content/nxpfile/an11239-boot-mode-jumper-settings-lpc1800-and-lpc4300-boards

It is the best for boot jumpers.

Regarding supported parts, we are moving away from publishing a list of supported parts because there are so many. Most parts are supported, but may not boot in high-speed QSPI mode. After booting, you can call spifi_init() from the spifi.lib included with the PDL or LPCOpen Platform driver libraries and switch to high-speed QSPI mode.

Regarding your other questions:
Boot header- you can put a header at the beginning of your code, in the QSPI. This will cause the boot ROM to copy code to RAM and run it there.
M4MEMMAP- this register is in the CPU and causes the memory region pointed to, to appear at 0x00000000. The boot ROM maps 0x80000000 to 0x00000000 but when your code executes, the starting address is determined by what the linker places in the vector table so it may branch to 0x00000000, or 0x14000000, or 0x80000000.

-Dave @ NXP

[lpcware]

Content originally posted in LPCWare by bunrockter on Thu Feb 14 00:40:49 MST 2013
Well I found a difference between the Hitex Quick start guide and the 4350 User's Manual.

Section 7.1 says to boot from SPIFI the boot[4:1] pins should be 0001
However the LPC435 UM says that they should be 0010

I changed the boot pins and it seems to be working ... for now. I add the fro now, because sometimes the board would randomly work (even for several uses in a row) and then stop working.

Am I correct in my theory that I had the boot pins wrong? If so, any thought as to why it would work randomly (like 5% of the time)

Also, the users manual shows that the S25FL256SAGMFI001 is supported. Are the 512Mb and 1Gb device also supported? It would be nice to have 64 or 128 MBs of Flash.

Thanks,

Bun

[lpcware]

Content originally posted in LPCWare by bunrockter on Thu Feb 14 00:19:10 MST 2013
I saw this in the SPIFI section of the Users manual (Just saw that it was updated!)

"If no header is present, it is assumed that the image is located on address 0x8000 0000
and is executed from there."

Is the header in my software or in the chip?

[lpcware]

Content originally posted in LPCWare by bunrockter on Wed Feb 13 23:58:39 MST 2013
IF I put a break point at the first actual instruction in the start up ASM file The register you are reffering to read as follows

VTOR       (0xE000ED08) = 0x0
M4MEMMAP   (0x40043100) = 0x80000000
PC(r15)                 = 0x140004F2

The PC is in the right place, but since the M4MEMMAP is at 0x80000000 does that mean that after a reboot the chip is trying to run SPIFI from the mirrored non debuggable location?

[lpcware]

Content originally posted in LPCWare by bunrockter on Wed Feb 13 15:29:10 MST 2013
Thanks for the quick reply. I am running out of the section at 0x1400 0000. The hard fault occurs before I remap  the vectors. When you refer to the M4mEMMAP is that a register or the memory map for the linker?

[lpcware]

Content originally posted in LPCWare by nxp21346 on Wed Feb 13 14:39:14 MST 2013
Hello,

I am curious about your setup of the M4MEMMAP and VTOR registers.

Based on your message, I am not sure where the problem lies, but double-check the M4MEMMAP and VTOR registers and also the program counter. If you are executing from QSPI at the high address 0x80000000 then breakpoints are not supported.
-Dave @ NXP