LPC1754 port ofNXP_LPC17xx_UsbHostLiteCMSIS example

[lpcware]

Content originally posted in LPCWare by wdawson61 on Mon Aug 23 14:24:58 MST 2010
Hi.  I'm trying to get the NXP_LPC17xx_UsbHostLiteCMSIS example running on some custom hardware, the usb host portion of which is based based on the Keil MCB1700. The code "Hard_Faults" upon stepping into the Rest_Handler.  I assume this is because the Reset_Handler is at an even address signifying "ARM" mode instead of THumb2.  Right?  My questoin is:

What is the correct way to ge tthe lpcXpresso toolchain to place the vectors at the appropriate address(es)?  I'm basing my assumption on tis article:


http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka12545.html


Any help would be greatly appreciated.

Regards,
Wade.

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Tue Aug 24 12:27:30 MST 2010
What version of LPCXPresso are you using? The ram size issue in the linker file for LPC1754 was reported some time ago (http://knowledgebase.nxp.com/showthread.php?t=256) and IIRC was fixed in version 3.4.0.

Regards,
CodeRedSupport

[lpcware]

Content originally posted in LPCWare by wdawson61 on Tue Aug 24 11:14:57 MST 2010
Got it.  The lpc1754 has two 16kb blocks of separate memory for a total of 32kb.  The lpcXrpresso-generated link file thinks its one 32k block.  Fixing the size to 16kb corrected the issue. 

BTW.  The Reset handler's first instruction was a push, decrementing the stack to 0x10007fe8 which matched the BFAR register.

-Wade

[lpcware]

Content originally posted in LPCWare by wdawson61 on Tue Aug 24 10:32:50 MST 2010
I'm using the generated linker script and the "stock" CMSIS startup code.

Here is the pertinent portion of the generated "nxp_lpc17xx_usbhostlitecmsis_Debug_mem.ld" file:


MEMORY
{
  /* Define each memory region */
  MFlash128 (rx) : ORIGIN = 0x0, LENGTH = 0x20000 /* 128k */
  RamLoc32 (rwx) : ORIGIN = 0x10000000, LENGTH = 0x8000 /* 32k */

}
  /* Define a symbol for the top of each memory region */
  __top_MFlash128 = 0x0 + 0x20000;
  __top_RamLoc32 = 0x10000000 + 0x8000;


I've selected the LPC1754 in the project settings and as you can see, the memory blocks and sizes  look correct.  Don't they?


Here's a jpeg of the register page after the fault happens:
https://docs.google.com/leaf?id=0B6F8ciDzBo1AMTM4OTlkNGQtMWMwZi00YmYxLThmM2MtYTk4ZmM4YmVkZDc1&sort=n...

Is the article (on the ARM website) I mentioned in my first post about vectors having to be on odd addresses applicable here?  It says that the M3 only supports thumb2 instruction set and that because of that, bit 0 of branch addresses must be set.  If this is so What could I be doing wrong?

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Mon Aug 23 23:57:33 MST 2010
Few things here:

1. What Hard Fault are you getting? If you look a the Core Registers Windows, immediately after the Hard fault, some pseudo-registers will be created (colored red) which will show the reason for the fault, and the CFSR. What do these show?

2. If it is faulting immediately, I would suggest that the stack may not be set up. The stack is address zero and the Reset vector is at address 4.

3. Are you using your own startup code, and linker script, or are you using the generated versions?
- If you are using your own, can you post them?
- If you are using the generated version, have you got the chip type set to LPC1754? If (for example) you are still using LPC1768 code, then the stack will be ointing to non-existing memory.

[lpcware]

Content originally posted in LPCWare by wdawson61 on Mon Aug 23 17:49:15 MST 2010
Hi.  Thanks for your response.  I am setting a breakpoint at the very start of Reset_handler() NOT main().  In fact, stepping "into" the first assembly instruction is causing an immediate vector to Hard_Fault. 

-Wade

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Mon Aug 23 14:59:17 MST 2010
How are you determining that just entering Reset_Handler() is causing the hard fault? I would suspect that it is much more likely that something done within the reset handler before it calls main() is causing the hard fault. 

Setting a breakpoint at the start of reset_handler() and then stepping through should help to identify the issue. You might also want to take a look at the knowledgebase entry[B] "Debugging a hard fault[/B]" at :

http://lpcxpresso.code-red-tech.com/LPCXpresso/node/52
[login required]

Regards,
CodeRedSupport