I have to erase flash on my device before starting a debug session

[jdupre]

I am experiencing a problem when starting a debug session after terminating a working debug session:

   15: Target error from Commit Flash write
   Cannot access core regs when target running.

In red at the bottom of the screen is:
   15: Target error from Commit Flash write Ep(08) Cannot access core regs when target running.  

Even if I cycle power on my device and un-plug / re-plug the LPC-Link V2 board I get the same error.
The only way I have been able to recover from this is to use the Program Flash tool to erase the flash on my device, and
cycle power on my device so it boots to ISP mode.

I've been writing and debugging code involving SCT0 on an LPC1517.  It's been working fine until today.

When I hit one of my breakpoints, even the restart button fails with this:
   11: Target error from Reset: (null)

I can continue working, but obviously it is an annoying problem. 

This is on version 8.1.4_606

I should add that my code size is approaching the limit of of the flash:  The binary is currently 64372 bytes.  Not much room to spare in the 64K flash, which might explain why it worked fine in the beginning but choked as my code grew.

[lpcxpresso_supp]

We've managed to track down a board with an LPC1517 fitted to it, and cannot replicate your problem so far - with multiple images of close to 64KB in size.

One thing we have noticed in the debug log you provided is that you project has a local config file - LPC1517.xml - which would indicate that you have probably modified the memory configuration for the project. Can you confirm any details?

Or perhaps you could provide your actual project for us to try - or at least the AXF file and map file?

https://community.nxp.com/message/630625 

Regards,

LPCXpresso Support

[jdupre]

I have confirmed that the problem does not have to do with code size, but rather something in my code is leaving the processor in a bad state that is only resolved by erasing the flash and rebooting.  When I remove the section of SCT code I was working on, the problem goes away.  Very strange.  I will report back when I discover anything more...

[jdupre]

Yes, I have customized the CPU settings so there is a single ram bank of 0x3000 starting @ 0x2000000, rather than the 3 separate RAM banks that were the default setting.

I also have a customized linker script that that shifts the entry point up in flash to accommodate for a boot loader.  This is file main_test_section.ldt, copied below.

I can provide the code privately; let me know where to send my project archive files.

- Joe

    /* MAIN TEXT SECTION */
    .text : ALIGN(${text_align})
    {
        FILL(0xff)
        __vectors_start__ = ABSOLUTE(.) ;
        KEEP(*(.isr_vector))

/* jmd: The default linker script is modified.  To disable this warning, goto Window | Preferences | LPCXpresso
   | Default Tool settings, and uncheck "...and compare with script generated using old-style templates." */

/* Here I use the "dot" command to move the program counter to move the main program code up to where it would be
   if loaded by the bootloader.  This is done so I can use the same binary to debug and create the image
   for the bootloader.  (The old way was to set the flash address to 0 when debugging, and then switch it to 0x6000
   when creating the image that would be passed to the bootloader image file creator (the encrypt utility.)
   
   When loaded by the bootloader, the vectors start at 0x6000, and then the program code is after the vectors.
   I need to know how much space the vectors use to make best use of space, but you can always go over.
   On the LPC15XX, vectors end at 0X110.  But I picked 0x120 (8 word boundary) so I can see it easy in memory displays.

   It is also possible to use the space between the vectors and program code to store information about the code
   (version number for example), so it can be read by the bootloader or other external tools.
    
*/

. = 0x6120;    /* Start the program code at this location */

/* Code Red uses the small space between the vectors and CRP to place the startup code (see cr_startup_lpc15xx.c) and the global_section_table that is referenced by the startup code.
   This needs to be moved up as well.  */

<#include "global_section_table.ldt" >

        *(.after_vectors*)

/* CRP will never be used with this code.  (Only in the bootloader.)  So do not allow the linker to try to inject
   the CRP value at 0x2FC. */

/* jmd removed: <#include "crp.ldt" > */

/* End of my linker modifications :dmj */

    } >${CODE}

    .text : ALIGN(${text_align})    
    {

<#include "main_text.ldt" >
<#include "main_rodata.ldt" >

<#include "cpp_info.ldt" >
    } > ${CODE}

[jdupre]

The problem happens in 8.2.2 also, and it does appear to be related to the size of the binary.

When I load a binary of 64244 bytes (either by starting a debug session or by using the Program Flash tool), the next time I try a debug session I get the error. This happens even if the new binary is smaller (I tried a 63628 byte build.)

The debugger does succeed at loading the new smaller image, it just can't enter the debug mode.  Repeated attempts to start a debug session fail.  However, If I cycle power on the device so the new, smaller binary runs, then the next time a debug session is attempted it works.

So it appears that loading and running a binary over a certain size (somewhere between 63626 and 64244 bytes) leaves the processor in a state that prevents the debugger from attaching.

LPCXpresso RedlinkMulti Driver v8.2 (Sep  5 2016 10:12:38 - crt_emu_cm_redlink build 725)
Found chip XML file in C:/Users/jmd/Documents/LPCXpresso_8.2.2_650/Translyte-Current/_Translyte/Debug/LPC1517.xml
(  5) Remote configuration complete
============= SCRIPT: LPC15RunBootRomConnect.scp =============
DpID = 2BA01477
APID = 0x24770011
Halt on reset vector catch
Halt on watchpoint write of ROMWSCTRL register
============= END SCRIPT =====================================
Probe Firmware: LPC-LINK2 CMSIS-DAP V5.147 (NXP Semiconductors)
Serial Number:  JQDQOSMU
VID:PID:  1FC9:0090
USB Path: \\?\hid#vid_1fc9&pid_0090&mi_00#7&900c419&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Vector catch on SYSRESETREQ signal
Emu(0): Connected&Reset. DpID: 2BA01477. CpuID: 410FC230. Info: <None>
Debug protocol: SWD. RTCK: Disabled. Vector catch: Enabled.
inspected v.2 On-chip Flash Memory C:\nxp\LPCXpresso_8.2.2_650\lpcxpresso\bin\Flash\LPC15xx_64K.cfx
image 'LPC15 (64K Flash) Jun 21 2016 11:53:29'
NXP: LPC1517  Part ID: 0x00000000
Connected: was_reset=true. was_stopped=true
LPCXpresso Free License - Download limit is 256K
Opening flash driver C:\nxp\LPCXpresso_8.2.2_650\lpcxpresso\bin\Flash\LPC15xx_64K.cfx
Writing 64244 bytes to address 0x00000000 in Flash
Erased/Wrote page  0-15 with 64244 bytes in 2080msec
Flash Write Done
Flash Program Summary: 64244 bytes in 2.08 seconds (30.16 KB/sec)
============= SCRIPT: LPC15RunBootRomReset.scp =============
Halt on reset vector catch
Halt on watchpoint write of ROMWSCTRL register
============= END SCRIPT ===================================
Target error from Commit Flash write: Ep(08). Cannot access core regs when target running.
(crt_emu_cm_redlink) terminating on communication loss: Pipe has been closed by GDB.

[lpcxpresso_supp]

Do you see the same behaviour if you try using a small example application? Do you also see the same behaviour if you try using LPCXpresso IDE v8.2.2? You can install the new version in parallel to your existing version.)

If you still see problems, please can you post the debug log from the IDE from a failed attempt to debug :https://community.nxp.com/message/630852 

Regards,

LPCXpresso Support