Debugger hang when declaring section assigned memory (TWR-MEM, TWR-K60F120M, KDS, J-Link)

[acurtis]

I've already a workaround to this problem, but wanted to share and see if anyone could help with the root cause

FYI, I'm using the TWR_MEM module with TWR-K60F120M kit, Kinetis Design Studio and Segger J-Link (basic).

I created a memory section called .mram @ 0x60000000.  I then create a global variable in main.c as such:

byte __attribute__ ((section (".m_mram"))) mram_buf[MRAM_BUF_SIZE] = {0}; 

This compiles fine and the .map file shows that mram_buf is where I expect it to be; however, when debugging, the debugger locks up like so:

-----START CONSOLE OUTPUT-----

SEGGER J-Link GDB Server V4.84c Command Line Version

JLinkARM.dll V4.84c (DLL compiled Apr 16 2014 18:53:07)

-----GDB Server start settings-----

GDBInit file:                  none

GDB Server Listening port:     2331

SWO raw output listening port: 2332

Terminal I/O port:             2333

Accept remote connection:      localhost only

Generate logfile:              off

Verify download:               on

Init regs on start:            on

Silent mode:                   off

Single run mode:               on

Target connection timeout:     5 sec.

------J-Link related settings------

J-Link Host interface:         USB

J-Link script:                 none

J-Link settings file:          none

------Target related settings------

Target device:                 MK60FN1M0xxx12

Target interface:              SWD

Target interface speed:        1000kHz

Target endian:                 little

Connecting to J-Link...

J-Link is connected.

Firmware: J-Link ARM V8 compiled Nov 25 2013 19:20:08

Hardware: V8.00

S/N: 58004845

Checking target voltage...

Target voltage: 3.30 V

Listening on TCP/IP port 2331

Connecting to target...Connected to target

Waiting for GDB connection...Connected to 127.0.0.1

Reading all registers

Read 4 bytes @ address 0x00000000 (Data = 0x20000000)

Target interface speed set to 1000 kHz

Resetting target 

Halting target CPU... 

...Target halted (PC = 0x00001290) 

R0 = 00000000, R1 = 00000000, R2 = 00000000, R3 = 00000000 

R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000 

R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000 

R12= 00000000, R13= 20000000, MSP= 20000000, PSP= 00000000 

R14(LR) = FFFFFFFF, R15(PC) = 00001290 

XPSR 01000000, APSR 00000000, EPSR 01000000, IPSR 00000000 

CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00 

Reading all registers 

Select auto target interface speed (2000 kHz) 

Flash breakpoints enabled 

Semi-hosting enabled (VectorAddr = 0x08) 

Semihosting I/O set to TELNET Client 

Read 4 bytes @ address 0x00001290 (Data = 0xB082B580) 

Downloading 488 bytes @ address 0x00000000 - Verified OK 

Downloading 16 bytes @ address 0x00000400 - Verified OK 

Downloading 16224 bytes @ address 0x00000410 - Verified OK 

Downloading 9160 bytes @ address 0x00004370 - Verified OK 

Downloading 4 bytes @ address 0x00006738 - Verified OK 

Downloading 4 bytes @ address 0x0000673C - Verified OK 

Downloading 2164 bytes @ address 0x00006740 - Verified OK 

Downloading 48 bytes @ address 0x00006FB8 - Verified OK 

Downloading 4 bytes @ address 0x60000000 - Verify failed 

Writing register (PC = 0x000012a4) 

Read 4 bytes @ address 0x000012A4 (Data = 0xB082B580) 

Read 2 bytes @ address 0x00000E7E (Data = 0xF001) 

Read 2 bytes @ address 0x00000E7E (Data = 0xF001) 

Read 2 bytes @ address 0x00000E7E (Data = 0xF001) 

Read 2 bytes @ address 0x00000E7E (Data = 0xF001)

Read 2 bytes @ address 0x00000E7E (Data = 0xF001) 

WARNING: Failed to reset CPU. VECTRESET has confused core. 

WARNING: CPU did not halt after reset. 

WARNING: CPU did not halt after reset. 

WARNING: S_RESET_ST not cleared 

ERROR: Error while identifying Cortex-M core. 

Resetting target 

Halting target CPU... 

...Target halted (PC = 0x00000F56) 

R0 = 00000000, R1 = 00000000, R2 = 00000000, R3 = 00000B38 

R4 = 00000003, R5 = FFFFFF89, R6 = 00000000, R7 = 1FFFFFA8 

R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000 

R12= 00000000, R13= 1FFFFFA8, MSP= 1FFFFFA8, PSP= 00000000 

R14(LR) = FFFFFFF9, R15(PC) = 00000F56 

XPSR 01000003, APSR 00000000, EPSR 01000000, IPSR 00000003 

CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00 

Reading all registers 

Read 4 bytes @ address 0x00000F56 (Data = 0x73FFF6C1) 

Reading 64 bytes @ address 0x1FFFFFC0 

WARNING: Failed to read memory @ address 0x1FFFFFC0

Setting breakpoint @ address 0x00000E7E, Size = 2, BPHandle = 0x0000

WARNING: No more breakpoint resources left

Starting target CPU...

-----END CONSOLE OUTPUT-----

Now the workaround that I've found is to not initialize the memory at declaration as follows:

byte __attribute__ ((section (".m_mram"))) mram_buf[MRAM_BUF_SIZE];

This allows the debugger to run and I can verify that indeed I have access to this memory section via "mram_buf".  So...I hope that might help someone/anyone who runs into this problem; however, I' wondering...does anyone know what's happening here (i.e. why initializing the buffer is causing the debugger lockup)?

Best Regards,

Aaron

[Jorge_Gonzalez · Accepted solution]

Hello Aaron:

If you or the linker itself initializes the buffer, those 0's appear in the s-record or binary file, and when the programming tool (in this case J-Link) tries to load those values, Flex Bus is not configured yet and it crashes.

You can indicate the linker not to initialize the ".m_mram" section with the NOLOAD directive. Check the next tutorial by colleague Erich Styger:

GNU Linker, can you NOT Initialize my Variable? | MCU on Eclipse

Hope this helps understanding the problem.

Regards!

Jorge Gonzalez

[acurtis]

That did it!  Your explanation (and Erich's blog) make complete sense, thanks so much.