Programming LPC1517

[lpcware]

Content originally posted in LPCWare by IanB on Wed Jul 15 06:52:55 MST 2015
My first attempt to program an LPC15xx and everything seemed OK at first.

After three recompiles I got a verify error at 0xC80  - an EEPROM failure after three rewrites? - unusual - but I changed the IC just to make sure.

First time I programmed the new one - verify error at 0xC80 - now I know it's fibbing. . . 65536 addresses to choose from and the same one faulty in two parts?

It also said: System rejected access at location 0xE000EDF0 - verify population of memory and peripherals.

How do I verify the population of the memory and peripherals? What is there at 0xE000EDF0 that it's so interested in?

Knowing the tangential relationship between LPCXPRESSO's error messages and their real causes, I did check a few other things:

My serial-wire debug lead is OK (that's the usual problem), I have a stiff enough power supply both on the target board and from the computer to the LPCLINK; and I haven't written anything daft to the CRP location,

and I tried again:

After a few more tries, it now says "target marked as non-debuggable".

Any clues?

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Fri Jul 17 10:20:54 MST 2015

The problem surfaced in a recent Mac OS X GDB release. It has been reported.

LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by IanB on Thu Jul 16 04:43:41 MST 2015
Yes - it's a Mac, but it used to work on v.7.3

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Jul 16 02:50:00 MST 2015
You did not answer my question - are you running a Mac? If so, Restart is not supported.

[lpcware]

Content originally posted in LPCWare by IanB on Thu Jul 16 02:46:19 MST 2015

---

Quote:
For restart, you might also want to try the "Terminate, Build and Debug" button in the Quickstart Panel that was introduced a release or two ago.

---

That's a really good addition, because it avoids that annoying error when it says it can't contact the probe because it is still in use; but restart was really handy because it could run the software from the beginning again without having to recompile and reprogram the flash.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Jul 16 02:39:29 MST 2015

---

Quote: IanB
It was 7.3, so I anticipated your next piece of advice and upgraded, which seems to have fixed it.

---

From the release notes the entry for LPCXpresso 7.4.0 contains ...

[list]
  [*]Fixed a flash programming issue for LPC15x7 parts
[/list]

For restart, you might also want to try the "Terminate, Build and Debug" button in the Quickstart Panel that was introduced a release or two ago.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Jul 16 02:25:03 MST 2015
Are you running on a Mac? If so Restart is permanently disabled due to a fundamental problem we have on Macs. It should be enabled on all other platforms.

[lpcware]

Content originally posted in LPCWare by IanB on Thu Jul 16 02:15:16 MST 2015
It was 7.3, so I anticipated your next piece of advice and upgraded, which seems to have fixed it.

(It seems auto-update wasn't working, and as I have only a 4Mb/s internet connection I tend not to upgrade big applications very often, but it was a year out of date!)

By the way, how to I get RESTART to work? It is perpetually greyed out. It was very handy.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Jul 15 13:27:37 MST 2015
Suggest you post your debug log...

https://www.lpcware.com/content/faq/lpcxpresso/debug-log

along with preferably  build able test project that shows up the problem, or at least your AXF file and the map file generated by the linker.

https://www.lpcware.com/content/faq/lpcxpresso/how-importexport-projects

Please also confirm what version of LPCXpresso you are using, and what debug probe.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by IanB on Wed Jul 15 10:59:53 MST 2015
I sorted out most of the problem - I had copied some startup routines from a LPC13 and certain registers (PDRUNCFG for instance) are different (so I had switched off power to something important)

However, it leaves me with one curious problem - the verify error. I have tried 3 chips and all have failed on verify consistently at 0xC80, and it is not a fictitious problem - whenever it tries to execute code from FLASH (or should I be technically correct and call it Flash EEPROM?) above that address, it goes completely mad. If I move a routine to below that address, it runs properly.

I'm not so daft as to think that NXP have made a batch of ICs with memory that won't program, so why does my programmer give up at 0xC80?

By the way

---

Quote:
http://www.differencebetween.net/technology/hardware-technology/difference-between-eeprom-and-flash/

---

is full of technical errors: There is both NAND and NOR flash, a NAND gate isn't slower than a NOR gate, you can access flash a byte at a time, program can be executed from flash (I'm sure that the LPC15xx doesn't copy it all to RAM before executing it) EEPROMs are the ones that are rewritten (that's why one would use them - to avoid having to rewrite a whole block). The main difference (from a user's point of view) is that in EEPROM you can modify a byte, but in flash you have to rewrite a block.

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Wed Jul 15 10:56:10 MST 2015
No. It is eeprom, not EPROM.

[lpcware]

Content originally posted in LPCWare by capiman on Wed Jul 15 10:40:08 MST 2015
Does your LPC15 have a window where UV can reach the inside of the chip?
Like old EPROMs:
https://www.google.de/search?q=EPROM&biw=1024&bih=574&site=webhp&tbm=isch&tbo=u&source=univ&sa=X&ved...

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Jul 15 08:20:21 MST 2015
No, if you want to recover you need to boot into ISP mode. Use ISP_UART0. This prevents any of _your_ code running and will stop in the on-chip Boot ROM. This will allow the debugger to gain access.

That address is one the of the Cortex-M3 Debug Registers. If the debugger cannot access it, you are stuffed...

Being pedantic, Flash is a version of EEPROM, but there are significant differences. Also not that the LPC15xx also has a separate EEPROM. So, if you are referring the the Flash, please use Flash, If you are referring to the EEPROM, then use EEPROM.

http://www.differencebetween.net/technology/hardware-technology/difference-between-eeprom-and-flash/

[lpcware]

Content originally posted in LPCWare by IanB on Wed Jul 15 07:38:13 MST 2015
Thanks.

I know of the ISP reset, but I have a LPC15, which has two ISP pins which are for CAN, USB and UART0; but I don't want to boot from either of those.

And what's this about verifying the population of the peripherals?


PS. Is the memory not Electrically Erasable Programmable Read Only Memory? (Are we both in the pedants' corner?) I'm certainly glad that I don't have to spend 20 minutes between each recompilation waiting for the UV eraser!

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Jul 15 06:55:00 MST 2015
Boot into ISP mode:
https://www.lpcware.com/content/faq/lpcxpresso/regaining-debug-access

As described here:
https://www.lpcware.com/content/faq/lpcxpresso/target-marked-not-debuggable

p.s. you are writing FLASH, not EEPROM!