AnsweredAssumed Answered

MCUXpresso and RT1050 HyperFlash Programming

Question asked by Ryan Shuttleworth on Nov 29, 2017
Latest reply on Dec 11, 2017 by Juan Mendoza

Hello I am using MCUXpresso IDE, version v10.1.0 [Build 589] [2017-11-14] with an MIMXRT1050-EVK SDK, version  2.3.0 (2017-11-16).  I have been experimenting with the hello_world_xip example to run an application out of HyperFlash but have noticed some issues that I was hoping someone could explain. 


When I attempt to program and debug the HyperFlash the programming phase completes as expected but I run into the following error which results in the termination of the debug session.


MCUXpresso RedlinkMulti Driver v10.1 (Nov  9 2017 16:47:53 - crt_emu_cm_redlink build 360)
Found chip XML file in /home/colby/workspace-nxp/evkmimxrt1050_demo_apps_hello_world_xip/Debug/MIMXRT1052xxxxx.xml
Reconnected to existing redlink server (PID 4294967295)
Connecting to probe 1 core 0 (server PID unknown) gave 'OK'
Probe Firmware: DAPLink CMSIS-DAP (ARM)
Serial Number:  0225000041114e450025300ac207002a92d1000097969900
VID:PID:  0D28:0204
USB Path: /dev/hidraw1
debug interface type      = <unknown> (DAP DP ID 0BD11477) over SWD
processor type            = Cortex-M7 (CPU ID 410FC270)
number of h/w breakpoints = 8
number of flash patches   = 0
number of h/w watchpoints = 4
Probe(0): Connected&Reset. DpID: 0BD11477. CpuID: 410FC270. Info: <None>
Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.
Content of CoreSight Debug ROM(s):
RBASE E00FD000: CID B105100D PID 000008E88C ROM dev (type 0x1)
ROM 1 E00FE000: CID B105100D PID 04000BB4C8 ROM dev (type 0x1)
ROM 2 E00FF000: CID B105100D PID 04000BB4C7 ROM dev (type 0x1)
ROM 3 E000E000: CID B105E00D PID 04000BB00C ChipIP dev SCS (type 0x0)
ROM 3 E0001000: CID B105E00D PID 04000BB002 ChipIP dev DWT (type 0x0)
ROM 3 E0002000: CID B105E00D PID 04000BB00E ChipIP dev (type 0x0)
ROM 3 E0000000: CID B105E00D PID 04000BB001 ChipIP dev ITM (type 0x0)
ROM 2 E0041000: CID B105900D PID 04001BB975 ARCH 23B:4A13r0 CoreSight dev type 0x13 Trace Source - core
ROM 2 E0042000: CID B105900D PID 04004BB906 CoreSight dev type 0x14 Debug Control - Trigger, e.g. ECT
ROM 1 E0040000: CID B105900D PID 04000BB9A9 CoreSight dev type 0x11 Trace Sink - TPIU
ROM 1 E0043000: CID B105F00D PID 04001BB101 System dev (type 0x0)
CM7 Rev. 0.0  DTCM: 512KB  ITCM: 512KB
LoUU: Level 2: LoC: Level 2
Level 1 Cache Type: Instruction+Data
ICache 32K: WT: Y WB: Y RA: Y WA: Y NumSets:  512 Assoc:   2 LineSize:  8
DCache 32K: WT: Y WB: Y RA: Y WA: Y NumSets:  256 Assoc:   4 LineSize:  8
Inspected v.2 External Flash Device on SPI using SPIFI lib MIMXRT1050-EVK_S26KS512S.cfx
Image 'MIMXRT1050-EVK_S26KS512SOct 19 2017 16:37:47'
Opening flash driver MIMXRT1050-EVK_S26KS512S.cfx
Sending VECTRESET to run flash driver
flash variant 'S26KS512S' detected (64MB = 256*256K at 0x60000000)
Closing flash driver MIMXRT1050-EVK_S26KS512S.cfx
NXP: MIMXRT1052xxxxx
( 65) Chip Setup Complete
Connected: was_reset=true. was_stopped=false
MCUXpresso Free License - Downloads unlimited
Awaiting telnet connection to port 3330 ...
GDB nonstop mode enabled
Opening flash driver MIMXRT1050-EVK_S26KS512S.cfx (already resident)
Sending VECTRESET to run flash driver
Writing 24584 bytes to address 0x60000000 in Flash
Erased/Wrote page  0-0 with 24584 bytes in 1754msec
Closing flash driver MIMXRT1050-EVK_S26KS512S.cfx
Flash Write Done
Flash Program Summary: 24584 bytes in 1.75 seconds (13.69 KB/sec)
Starting execution using system reset and halt target
flash - system reset failed - Ee(FF). Redlink interface error 255.
Target error from Commit Flash write: Ee(FF). Redlink interface error 255.
GDB stub (crt_emu_cm_redlink) terminating - GDB protocol problem: Pipe has been closed by GDB.
error closing down debug session - Ee(FF). Redlink interface error 255.


After examining the application README.txt and reviewing some online posts I realize that I can attach the debugger to a running target and debug, however, there appear to be significant limitations to this approach:


1) Given that the application is already running when I attach, I cannot debug issues that occur early on in the init. process which is often the time when stepping through code is most necessary.

2) Any attempt to reset the processor via the debug "Restart" menu option or hardware reset terminates the debug session and I'm back at issue 1


I am assuming that this is a known limitation or expected behavior but it is very inconvenient. Is there any plan to fix it?

Is there any way to step through code in the early init. stages using the attach and debug process?