New V7.1.1 debug woes with 4357 M4 projects that don't begin at 0x1a000000

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

New V7.1.1 debug woes with 4357 M4 projects that don't begin at 0x1a000000

318 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by jonper on Thu Apr 03 13:35:38 MST 2014
Somewhere between LPCXpresso 6.1.4 and 7.1.1 we have lost the ability to simply debug LPC4357 M4 internal flash projects that do not begin at the base of flash bank BankA. Our formerly working projects targets a custom 4357 board and server app at 0x1b020000 which shows this quite repeatably but does not transport well for a sanity check request.

The cleansed example below should work (to show the repeatable failure) with any 4357 board that does not have esoteric startup requirements and which can compile, load, and debug a Quickstart "New Project..." LPC4357 (M4 Basic) C Project with no need of any supporting libraries. The Keil MCB4357 EVB we tested did serve demonstrate the problem.

We have only tested under Windows, but with both a 64-bit Win7SP1 box and 64-bit Win8.1 laptop, with two different LPC-Link2s, on USB, USB2, and USB3 ports, with and without external hubs. In all cases, both 614 and 711 compile and load, but only 614 proceeds to debug normally while 711 requires awkward coercing to debug. There's also nothing magic about the 0x1a040000 test address, it just presents the simplest setup with the fewest steps.

1. Create and open a new "C:\nxp\WontDbg1a04ws" workspace

2. Create the test LPC4357 M4 basic C project:
[list]
  [*]   Click New Project... in the Quickstart Panel and select:
  [*]   LPC4x
  [*]     LPC43xx (Cortex-M4 basic)
  [*]       C Project                    [Next>]
  [*]   Project name:        WontDbg1a04 [Next>]
  [*]   Target selection:    LPC4357     [Next>]
  [*]   CMSIS Core library:  None        [Next>]
  [*]            [Next>] [Next>] [Next>] [Finish]
[/list]
3. Change the new project MCU Settings
[list]
  [*]   Click Edit 'WontDbg1a04' project settings in the Quickstart Panel.
  [*]     Click C/C++ Build
  [*]       MCU Settings
  [*]         [Edit...] button (to open the Memory configuration editor)
  [*]            Click the MFlashA512 top line in the table
  [*]              click the [Split] button near the bottom
  [*]               click the [UP] button at right.
  [*]        Click the Memory configuration editor [ OK ] button.
  [*]      Visually confirm that 0x1a04000 is now the first flash address.
  [*]   Click the Properties dialog [ OK ] button.
[/list]
4. Debug the new project
[list]
  [*]  Click Debug 'WontDbg1a04' [Debug] in the Quickstart Panel.
  [*]Click [ OK ] to Connect to emulator -- Redlink Server dialog
  [*]Click the box for the M4 device and click [ OK ]
[/list]
What happens next varies by what app currently resides at 0x1a000000. What will not happen is the main.c window popping up with the instruction pointer stopped in the while(1); loop, and waiting for your commands as it would have without the MCU changes.

If what was residing at the base 0x1a000000 happens to be the remnant of a previous session that used the same (M4 Basic) C Project without MCU memory changes, then what usually happens on the first attempt with a new workspace and new project is that you will see a editor named 0x1a0003ac (or similar) and a message in red "No source available for 0x1a0003ac" followed below by a [View Disassembly...] button. Clicking that will open a blank Disassembly panel.

Clicking the Run menu at top will show most of the control items dimmed as expected for a running app, so choose Suspend to get it to stop. The Disassembly panel will fill with instructions starting near the address shown in the warning window, and the Registers view if accessed will also show that same address for pc, but still no main.c debug window appears. The Run menu items (and icons) will also now become undimmed but clicking them will not until you enable Instruction Stepping Mode (top right i-> icon), then click inside the Disassembly panel. At that point Run->Step Into will now step through assembly instructions, but still be no main.c debug window offerred.

If you then open the WontDbg1a04.map file from the Debug folder and scroll to line 190 you can find and copy the address of the ResetISR function and paste that into the Registers view pc box (hit enter for it to take). Run->Resume will now open the main.c debug window at the while(1); loop, and the Disassembly window will verify that we're in the memory space.

Any ideas on how to get back to the V6 behavior without having to forgo the steady stream of enhancements would be much appreciated?

Thanks
0 Kudos
4 Replies

296 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by jonper on Fri Apr 04 08:26:19 MST 2014
I really hoped it would turn out be something as simple as that!

Your fix restored simple debugging to the contrived example as well as to a largish LPCOpen 2.09 based app in BankB's 1B020000. With both of these existing projects, I did get squirrely results until forcing Launch Configurations>Delete current followed by Launch Configurations>Create and open new... (to reinstall the proper Reset script). If you publish a FAQ, it might be worth mentioning that possibility.

Thanks again for quick and effective help.
0 Kudos

296 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by lpcxpresso-support on Fri Apr 04 01:20:20 MST 2014
For non-default startup scenarios like this, you will need to select one of the provided Reset scripts in the launch configuration. [I thought this was FAQ'd but cannot find it - I will chase up why this is not published]

[list]
  [*]Open the Launch configuration for your project
  [*]Switch to the Debugger tab
  [*]Ensure "Redlink Server" is the selected emulator
  [*]Scroll through the Configuration Options until you see Reset Script and click on the field
  [*]Press the ... button and then the Browse Scripts button
  [*]Select LPC18LPC43InternalFLASHBootResetscript.scp
  [*]Press OK
  [*]
[/list]
Now start your debug session. This should now work as expected.

Of course, when you power-on, or Reset your board, the internal boot loader will not know your code is located at this location, so it will not run...
0 Kudos

296 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by jonper on Thu Apr 03 15:45:30 MST 2014
Thanks for the quick reply.

Newly created workspace and project as previously described and debuged to Keil MCB4357 using LPCXpresso 7.1.1:

LPCXpresso RedlinkMulti Driver v7.1 (Apr  1 2014 09:29:42 - crt_emu_cm_redlink build 73)
Found chip XML file in C:/nxp/WontDbg1a04ws/WontDbg1a04/Debug/LPC4357.xml
Emu(0): Conn&Reset. DpID: 4BA00477. CpuID: 410FC240. Info: (null)
Debug protocol: JTAG. RTCK: Disabled. Vector catch: Disabled.
Loaded LPC18x7_43x7_2x512_BootA.cfx: LPC18x7/LPC43x7 Flash 2x512KB @0x1A000000 (Boot Bank A) Jul 22 2013 10:38:28  On-chip Flash Memory
Connected: was_reset=false. was_stopped=false
v LPCXpresso Free License - Download limit is 256K
Writing 940 bytes to 1A040000 in Flash (assumed clock: unknown)
Erased/Wrote page  11-11 with 940 bytes in 478msec
Flash write Done
Stopped (Was Reset)  [Reset from Unknown]



Newly created workspace and project as previously described and debuged to Keil MCB4357 using LPCXpresso 6.1.4:

LPCXpresso RedlinkMulti Driver v6.0 (Jan  8 2014 13:55:09 - crt_emu_cm_redlink build 256)
Found chip XML file in C:/nxp/WontDbg1a04ws614/WontDbg1a04/Debug/LPC4357.xml
(  5) Remote configuration complete
Emu(0): Conn&Reset. DpID: 4BA00477. CpuID: 410FC240. Info: (null)
Debug protocol: JTAG. RTCK: Disabled. Vector catch: Disabled.
Loaded LPC18x7_43x7_2x512_BootA.cfx: LPC18x7/LPC43x7 Flash 2x512KB @0x1A000000 (Boot Bank A) Jul 22 2013 10:38:28  On-chip Flash Memory
Connected: was_reset=true. was_stopped=false
v LPCXpresso Free License - Download limit is 256K
Writing 948 bytes to 1A040000 in Flash (assumed clock: unknown)
Erased/Wrote page  11-11 with 948 bytes in 430msec
Flash write Done
============= SCRIPT: LPC18LPC43InternalFLASHBootResetscript.scp =============
Boot from FLASH image pc/sp reset script
PC = 0x1A040301
SP = 0x10008000
XPSR = 0x01000000
VTOR = 0x1A000000
============= END SCRIPT =====================================================

Stopped: Breakpoint #1

Both were run on the exact same equipment.

I don't if this matters, but the change from 711 to 614 would not allow download until I did a full PC restart. The Error reported by target and contained the text:
02: Failed on connect
Invalid probe index.
31: No connection to emulator device.

I copied from another error dialog:
Error in final launch sequence
  Failed to execute MI command:
-target-select extended-remote | crt_emu_cm_redlink -msg-port=50513 -g -mi -2 -pLPC4357 -vendor=NXP -ResetScript=LPC18LPC43InternalFLASHBootResetscript.scp -ProbeHandle=1 -CoreIndex=0 -x C:/nxp/WontDbg1a04ws614/WontDbg1a04/Debug
Error message from debugger back end:
Remote communication error.  Target disconnected.: No error.
  Remote communication error.  Target disconnected.: No error.

And I copied from the debug log:
LPCXpresso RedlinkMulti Driver v6.0 (Jan  8 2014 13:55:09 - crt_emu_cm_redlink build 256)
Found chip XML file in C:/nxp/WontDbg1a04ws614/WontDbg1a04/Debug/LPC4357.xml
Failed on connect: Ee(38). Invalid probe index.
No connection to emulator device

Thanks
0 Kudos

296 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by lpcxpresso-support on Thu Apr 03 14:53:13 MST 2014
Please post your debug logs, from both LPCXpresso v6 and v7.

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

Regards,
LPCXpresso Support
0 Kudos