Loading to RAM instead of Flash not working in 8.1.2?

[lpcware]

Content originally posted in LPCWare by mch0 on Thu Mar 10 01:05:53 MST 2016
Hello,

I'm loading my applications into RAM instead of internal Flash even if the µC has such a Flash.
This worked until 8.1.0.
Since I was also a victim of the redlink server problem in 8.1.0 I updated to 8.1.2.
Now the very same(!) project which loaded and debugged perfectly in 8.1.0 does not load in 8.1.2 correctly any more.

I made sure the code is placed on RAM (*.lss file checked), I made sure the reset script is "LPC18LPC43RamReset.scp".
Yet the code does not seem to be loaed into the proper place at 0x10000000.

I can connect to the target, I checked that with the memory monitor (SWD).
Loading & Debugging when using the internal flash works in 8.1.2, BTW.

I change between RAM and Flash configurations by:

- editing the MCU setting (w/ or w/o flash section)
- changing the reset script (internal flash or ram)
- making sure by looking at the *.lss that the code is linked to the correct adresses (just the first time after a change of MCU settings)

As said, up to 8.1.0 this works, with 8.1.2 ist stopped working for RAM as code target.

Has anything changed here?
Do I have to do anything else to convince the tool to load the code into RAM?

Regards,

Mike

[lpcware]

bump

[lpcware]

Content originally posted in LPCWare by mch0 on Thu Mar 17 04:40:39 MST 2016
Thanks for looking still into that.
For the moment I am back in the (debug-) game again.

I have identified my setting "Vector Catch = true" as the source of the problem at this point.
With this setting I get this result:

----------------------------------------------------------------
LPCXpresso RedlinkMulti Driver v8.1 (Mar 11 2016 13:34:34 - crt_emu_cm_redlink build 672)
Probe Firmware: LPC-LINK2 CMSIS-DAP V5.147 (NXP Semiconductors)
Serial Number:  CWG0CZKR
VID:PID:  1FC9:0090
USB Path: \\?\hid#vid_1fc9&pid_0090&mi_00#a&2aa711f0&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Vector catch on SYSRESETREQ signal
Cannot halt processor
Cannot halt processor
Emu(0): Connected&Reset. DpID: 2BA01477. CpuID: 410FC240. Info: <None>
Debug protocol: SWD. RTCK: Disabled. Vector catch: Enabled.
Cannot halt processor
Failed on chip setup: Ep(04). Cannot halt processor.
----------------------------------------------------------------

It does not matter whether I link/load to FlashA or RAM, it will fail in both cases.

With "Vector Catch = false" it works in both scenarios.
I use 8.1.4 + SWD as protocol and have verfied this behaviour for two different probes/targets:

2x LPCLink2, for 4370 only the RAM scenario, of course
LPC4327 as target and a LPCLink2-compatible probe (same CMIS-DAP FW), both RAM/Flash tested

Since I can load+debug with "Vector Catch = false" there is no urgent problem for me right now.
If I can provide a better analysis later, I'll keep you posted. It might take a while, since the project itself has priority now.

Regards,

Mike

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Mar 16 04:19:53 MST 2016
Exactly which part are you using?

I assume you are using an LPC-Link2? If so are you using pre-programmed firmware (if so which version) or allowing LPCXpresso IDE to soft load? If you are softloading, have you rebooted the probe between using LPCXpresso IDE v8.0.0 and v8.1.4?

Does your LPCXpresso IDE v8.1.4 project have the Ramreset script specified in the launch configuration setting?

Can you post your actual debug log and redlinkserv log from LPCXpresso IDE v8.1.4?

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

As an aside, it might be worth seeing if you see the same behaviour with the internal flash erased. Or at least try booting into ISP mode before starting a debug session.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by mch0 on Wed Mar 16 04:00:42 MST 2016
Thanks for the update!
I installed 8.1.4_606 and tried with a blank projekt to link to RAM (with the Managed Script Method).

The result was strange:
On the first try the debugger stopped at some undefined location, far away from the default main entry.
However, with the Memory Monitor I could see that the program was loaded to 0x10000000 (which is a progress).
I then went back to modifying the MCU settings as that worked previosly.
As a result I can't connect to the target, no matter what I do. The debugger dies with "Cannot halt core" every time.

With totally unchanged HW I can still debug using 8.0.0_256.
So it can't be a pure HW malfunction.

I'm using SWD as protocol, btw.

I'll try some other things before I come back. At this point there is progress (dowload to RAM ok now, at least once), but other problems are still there or new with my setup. But maybe I can find a solution or at least narrow down the problem more precisely.
Just to let you know for now.

Best regards,

Mike

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Mar 16 01:19:07 MST 2016
LPCXpresso IDE v8.1.4, which we have just released, should resolve this issue.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Mar 10 18:09:26 MST 2016

We can confirm an LPCXpresso 8.1.2 problem with the Load Application to RAM feature. We'll have a fix available soon.

Thanks and regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Mar 10 11:28:29 MST 2016

We'll investigate this. A quicker way of setting up a RAM project can be done using the "Link application to RAM" check box at:

File -> Properties -> C/C++ Build -> Settings -> Tool Settings <tab> -> Managed Linker Script

This way, you might avoid editing the MCU Settings memory configuration.

Thanks and regards,
LPCXpresso Support