lpcware

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

Discussion created by lpcware Employee on Jun 15, 2016
Latest reply on Jun 15, 2016 by lpcware
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

Outcomes