LPC1788 registers missing in Xpresso?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ianholmes on Tue Feb 19 03:48:37 MST 2013
I'm trying to trace a code fault on the 1788 and I've not found a few registers in the peripheral view.

Particularly (at the moment)
EEADDR (0x0020 0084) (expected in the FLASH CTRL set)
ISER1 (0xE000 E104) (expected in the NVIC set)

Am I looking in the wrong place, or they missing>

I am trying to work out why reading or writing a commond to the EEPROM stalls the FLASH programmer for subsequent downloads unless I prevent program execution with the ISP entry mode.

[SIZE=1]

Version: LPCXpresso v5.0.14 [Build 1109] [2012-12-19]

[/SIZE]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by whitecoe on Fri Mar 08 13:16:06 MST 2013

Quote: ianholmes

It seems that the Code Red environment we use does not reset the target unless it can not communicate (found with a fast scope and confirmed with a logic analyser), so this becomes difficult to recover.

Did you try turning on "vector catch"?

HTH!

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Brutte on Fri Mar 08 10:02:16 MST 2013

Quote: ianholmes
(...) and I've not found a few registers in the peripheral view.

Switch to Eclipse and EmbSysRegView.
There you can add any register view or name it the way you like.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ianholmes on Fri Mar 08 05:54:18 MST 2013
Thanks.

In case anyone comes here after a link to EEPROM/Flash programming/debugger issues.

It is vital, and not well documented, that the EEPROM status flags are cleared whenever access is made to it. Primarily this refers to bits 26 and 28 (of the EEPROM Status register). If either flag is set then it is not possible for the IAP Flash programmer (that is used to download via SWD) to reprogram the application.

It seems that the Code Red environment we use does not reset the target unless it can not communicate (found with a fast scope and confirmed with a logic analyser), so this becomes difficult to recover.

To recover follow this process:
Attempt to download (fails and "no dissembly available" message appears usually
Assert the ISP pin (pull low)
Now click the reset icon in the debug section (to the left of the green start arrow), NOT THE STOP (red square). This should reset the target which will enter ISP mode at this point. Now the target is in ISP it is safe to halt the debug session
Press the RED stop square icon to stop debug session
Down load the new application. This will attempt to run but will have no sorce because the ISP is still set.
PAUSE the debug session
Remove the ISP assert
Click the Restart icon

You should be now executing your new code.

I'm sure this repeats information that is already posted, but hopefully it explains it in a way that shows why the process is in this order. What we are doing is following the boot process flowchart in the ARM manual and taking advantage of the ISP route. :)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Tue Feb 19 06:24:24 MST 2013

Quote: ianholmes

EEADDR (0x0020 0084) (expected in the FLASH CTRL set)

The part specific peripheral description in LPCXpresso for the LPC177x_8x are generated from a datafile we receive from NXP, which appears to have this register missing. We'll discuss this with NXP with the aim of fixing in a future release.

In the meantime you'll need to access the memory directly yourself, either through a Memory View, or by dropping down to the gdb command line:

http://support.code-red-tech.com/CodeRedWiki/AccessingGDBwithinGUI

and using a command along the lines of...

[FONT=Courier New]x /wx 0x00200084[/FONT]

Quote:
ISER1 (0xE000 E104) (expected in the NVIC set)

If you look in the NVIC peripheral, you'll see that the register at this address is provided, but with a slightly different name - IRQ_32_63_SE (IRQ 32 to 63 Set Enable Register).

Regards,
CodeRedSupport