FAQs
English (US) 日本語 | Japanese 中文 | Chinese (Simplified)

Can not debug MIMXRT1050-EVK Rev. A4 in OSX

cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Can not debug MIMXRT1050-EVK Rev. A4 in OSX

‎12-14-2017 08:52 AM
4,447 Views
ryanshuttlewort
Contributor IV

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 was previously using a Rev. A3 of the MIMXRT1050-EVK and was able to program and debug via the OpenSDA interface under both Linux and OSX.  Our new A4 boards do not enumerate under Linux and although they enumerate under OSX, they can not be debugged under OSX.  When a debug is attempted the following error occurs:

MCUXpresso RedlinkMulti Driver v10.1 (Nov  9 2017 16:49:12 - crt_emu_cm_redlink build 360)
Found chip XML file in /Users/ryan/Documents/MCUXpressoIDE_10.1.0/workspace/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:  0227000041114e45003d300dc40300105ab1000097969900
VID:PID:  0D28:0204
USB Path: USB_0d28_0204_14220000_ff00
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
chip initialization failed - Ee(FF). Redlink interface error 255.
failed to find a target memory area to use to test the Debug Access Port
required information about vendor NXP chip MIMXRT1052xxxxx not found
Failed on chip setup: Ec(01). Invalid part, XML, or configuration.
error closing down debug session - Ee(FF). Redlink interface error 255.‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I have tried changing the DAPLink firmware as I had to do on the A3 revisions but this did not fix the issue.

Any insight into this issue would be appreciated, thanks.

0 Kudos
Reply
7 Replies

‎12-20-2017 10:00 AM
3,512 Views
lpcxpresso_supp
NXP Employee
NXP Employee

Hi Ryan,

We now have access to the MIMXRT1050-EVK Rev 4 board and have observed the following.

1 - these board are programmed with the latest version of the OpenSDA debug firmware:

# DAPLink Firmware - see https://mbed.com/daplink
Unique ID: 0227000041114e45003c300cc403002e5ab1000097969900
HIC ID: 97969900
Auto Reset: 0
Automation allowed: 0
Overflow detection: 0
Daplink Mode: Interface
Interface Version: 0244
Bootloader Version: 0242
Git SHA: 853df431d81359e822f49363891f877f17d31efb
Local Mods: 0
USB Interfaces: MSD, CDC, HID
Bootloader CRC: 0x73707d49
Interface CRC: 0x565000e7
Remount count: 0

2 - they still contain problematic code within the Hyperflash, so this needs erasing before a successful debug operation can be performed.

3 - we have not been able to duplicate any enumeration issues on Mac or Linux when debugging and powering the board via the OpenSDA debug connection.

4 - using an SDK downloaded from Welcome | MCUXpresso SDK Builder we have not seen any debug problems using either RAM based or the single xip examples. Similarly, projects created via the new project wizard (which are also flash based and xip) also program and run without issue. (from Mac, Linux (16.04 real hardware) and Windows). Note: we have seen issues with pre-release versions of the SDK, so please be sure you are using a fresh download.

With regard to the difference variants of OpenSDA binaries, I would expect the Hyperflash variant to support programming of the Hyperflash via drag and drop, and similarly the QSPI variant will support the QSPI via drag and drop (but this would obviously only be applicable for boards modified to use the onboard QSP and has not been tried by the IDE team). WRT generic debug, I would not expect there to be a difference.

Obviously, this doesn't provide a solution to the problems you are seeing - so please can you tell us:

Assuming you can get a board to enumerate: If the hyperflash is erased and the board is power cycled... does a RAM based project debug. Since flash programming operations are by their nature, RAM applications, and you report the flash programming succeed (in earlier logs) I would expect these to work.

If you more than one of the Rev 4 boards, and if so, is the behaviour identical between these boards?

Have you made any attempt to re-program the OpenSDA firmware on these Rev4 boards?

We will continue to investigate this report pending a response.

Yours,

MCUXpresso IDE Support

0 Kudos
Reply

‎12-21-2017 11:30 AM
3,512 Views
ryanshuttlewort
Contributor IV

Thanks for the reply, this helps.  I am still having enumeration issues after flash bulk erase but I have found a strange way of bringing the boards back to life.  I bring them up first in maintenance mode, where they do enumerate and after that I can re-plug and they enumerate normally.  I have no idea why this would work.  I have been using OpenSDA with rev. A3 and A4 boards because I can not write flash via JLINK.

0 Kudos
Reply

‎12-15-2017 10:08 AM
3,512 Views
lpcxpresso_supp
NXP Employee
NXP Employee

Hi Ryan,

I appreciate you have been through the loop a few times now, but please bear with us and confirm some things:

1 - when you say the REV A4 (opensda) probe fails to enumerate on Linux do you mean:

a) is not found by a probe discovery performed by the IDE or

b) is not reported by an lsusb

Also, please confirm which Linux variant you are using.

2 - On Windows, please open up the DETAILS.TXT file (from the RT1050-EVK drive) in an editor and paste a copy.

3 - Set SW7 to prevent hyperflash boot, and erase the flash as you have done before.

Power cycle the board.

Import the igpio_led_output example. Then by default runs from RAM, so confirming whether this works will help.

4 - Next, create a simple New Project taking all the default options. Please confirm if you can debug this.

As you may have surmised, we do not have immediate access to a REV A4 so this information will be most helpful.

Yours,

MCUXpresso Support

0 Kudos
Reply

‎12-15-2017 10:31 AM
3,512 Views
ryanshuttlewort
Contributor IV

Hello, here are my answers.

When I say fails to enumerate I mean USB fails to enumerate, no RT1050 drive shows up and dmesg shows no USB activity whatsoever.  And because USB doesn't enumerate, MCUXpresso can't  see the probe at all.  I have tried Ubuntu 14.x (a VM) and 16.x (a PC).  The 16.x behavior is somewhat better in that it occasionally enumerates USB.

The DETAILS.TXT file is long, sordid tale.  If you go to to the OpenSDA debug adapter site you can download two firmware files, k20dx_mimxrt1050_evk_qspi_if_crc.bin and k20dx_mimxrt1050_evk_hyper_if_crc.bin.  Bizarrely, it is k20dx_mimxrt1050_evk_qspi_if_crc.bin that lets me program HyperFlash on the Rev. A3 boards (?!) and I have confirmed this repeatedly.  Surely the files are mislabeled, if not then please carefully explain this naming convention.  Anyway, here is what the DETAILS.TXT contain for each FW/Rev variant.


DETAILS.TXT - Rev A4 - k20dx_mimxrt1050_evk_hyper_if_crc.bin

# DAPLink Firmware - see https://mbed.com/daplink
Unique ID: 0227000041114e45003d300dc40300105ab1000097969900
HIC ID: 97969900
Auto Reset: 0
Automation allowed: 0
Overflow detection: 0
Daplink Mode: Interface
Interface Version: 0244
Bootloader Version: 0242
Git SHA: 853df431d81359e822f49363891f877f17d31efb
Local Mods: 0
USB Interfaces: MSD, CDC, HID
Bootloader CRC: 0x73707d49
Interface CRC: 0x565000e7 (TAKE NOTE!)
Remount count: 0

DETAILS.TXT - Rev A4 - k20dx_mimxrt1050_evk_qspi_if_crc.bin

# DAPLink Firmware - see https://mbed.com/daplink
Unique ID: 0227000041114e45003d300dc40300105ab1000097969900
HIC ID: 97969900
Auto Reset: 0
Automation allowed: 0
Overflow detection: 0
Daplink Mode: Interface
Interface Version: 0244
Bootloader Version: 0242
Git SHA: 853df431d81359e822f49363891f877f17d31efb
Local Mods: 0
USB Interfaces: MSD, CDC, HID
Bootloader CRC: 0x73707d49
Interface CRC: 0x16f4aa60 (TAKE NOTE!)
Remount count: 0

DETAILS.TXT - Rev A3 - k20dx_mimxrt1050_evk_qspi_if_crc.bin (BUT USING HYPERFLASH?! SURELY THE FILES ARE MISLABELED!)

# DAPLink Firmware - see https://mbed.com/daplink
Unique ID: 0227000041114e450025300ac207002a92d1000097969900
HIC ID: 97969900
Auto Reset: 0
Automation allowed: 0
Overflow detection: 0
Daplink Mode: Interface
Interface Version: 0244
Bootloader Version: 0242
Git SHA: 853df431d81359e822f49363891f877f17d31efb
Local Mods: 0
USB Interfaces: MSD, CDC, HID
Bootloader CRC: 0x73707d49
Interface CRC: 0x16f4aa60 (TAKE NOTE!)
Remount count: 0

Regarding your questions 3 and 4. Yes, I have done all of this over and over and have been careful to follow each step, DIP switches and all.  As I mentioned, the flash erasing process worked and had some positive effect but the A4 probes are still unstable, giving the messages I pasted in the previous response.

The behavioral differences in the A4 boards are not subtle and the problems exist across Linux, OSX and Windows.  There is clearly something different about them.  The only HW change in the schematic is "Update BOM only to change CSI related serial 0ohm resistor from DNP to mount, mount R352 and DNP R353".  On a whim, I've tried reverting this change to no avail.

Regards

0 Kudos
Reply

‎12-14-2017 09:58 AM
3,512 Views
ryanshuttlewort
Contributor IV

Update, I have found that Windows is giving me the same issue with the Rev. A4 boards.

0 Kudos
Reply

‎12-14-2017 09:24 AM
3,512 Views
lpcxpresso_supp
NXP Employee
NXP Employee

Please see: https://community.nxp.com/thread/465595#comment-969444 

Regards,

MCUXpresso IDE Support

0 Kudos
Reply

‎12-14-2017 04:29 PM
3,512 Views
ryanshuttlewort
Contributor IV

Hello. The mass erase procedure had some effect but enumeration under OSX is unreliable as is programming and debugging.  There is still no enumeration under Linux at all.  Please see the following programming errors, thanks.

MCUXpresso RedlinkMulti Driver v10.1 (Nov  9 2017 16:49:12 - crt_emu_cm_redlink build 360)
Found chip XML file in /Users/ryan/Documents/MCUXpressoIDE_10.1.0/workspace/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:  0227000041114e45003d300dc40300105ab1000097969900
VID:PID:  0D28:0204
USB Path: USB_0d28_0204_14220000_ff00
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
Connected: was_reset=false. was_stopped=true
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 24668 bytes to address 0x60000000 in Flash
Erased/Wrote page  0-0 with 24668 bytes in 1375msec
Closing flash driver MIMXRT1050-EVK_S26KS512S.cfx
Flash Write Done
Flash Program Summary: 24668 bytes in 1.38 seconds (17.52 KB/sec)
Starting execution using system reset and halt target
Stopped: Halt
After error Nn(05). Wire ACK Fault in DAP access -
Failed to read address register in DAP - Ee(FF). Redlink interface error 255.
After error Em(17). Debug port inaccessible after access at location 0x600029F0 -
Failed to read address register in DAP - Ee(FF). Redlink interface error 255.
Target error from Read Memory: Em(17). Debug port inaccessible after access at location 0x600029F0
After error Nn(05). Wire ACK Fault in DAP access -
Failed to read address register in DAP - Ee(FF). Redlink interface error 255.
After error Em(17). Debug port inaccessible after access at location 0x600029F0 -
Failed to read address register in DAP - Ee(FF). Redlink interface error 255.
Target error from Read Memory: Em(17). Debug port inaccessible after access at location 0x600029F0


MCUXpresso RedlinkMulti Driver v10.1 (Nov  9 2017 16:49:12 - crt_emu_cm_redlink build 360)
Found chip XML file in /Users/ryan/Documents/MCUXpressoIDE_10.1.0/workspace/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:  0227000041114e45003d300dc40300105ab1000097969900
VID:PID:  0D28:0204
USB Path: USB_0d28_0204_14220000_ff00
connection failed - Ee(FF). Redlink interface error 255... Retrying
Failed on connect: Ee(FF). Redlink interface error 255.
Connected&Reset. Was: NotConnected. DpID: 00000000. CpuID: 00000000. Info: <None>
Last stub error 0: OK
Last sticky error: 0x0 AIndex: 0
Debug bus selected: MemAp 0
DAP Speed test unexecuted or failed
Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.
(100) Target Connection Failed
error closing down debug session - Ee(FF). Redlink interface error 255.

0 Kudos
Reply