AnsweredAssumed Answered

things that happen to start debugging RT1051

Question asked by Massimiliano Cialdi on Dec 19, 2018
Latest reply on Dec 19, 2018 by Buck Fobb

When I launch the debug of an RT1051 from MCUXpresso on the debugger console there is this

 

[19-12-2018 03:55:15] Executing Server: /opt/SEGGER/JLink_V632h/JLinkGDBServerCLExe -nosilent -swoport 2332 -select USB=504400379  -telnetport 2333 -singlerun -endian little -noir -speed auto   -port 2331   -vd -device MIMXRT1051xxxxB -if SWD -halt -reportuseraction
SEGGER J-Link GDB Server V6.32h Command Line Version

JLinkARM.dll V6.32h (DLL compiled Jul  5 2018 18:14:58)

Command line: -nosilent -swoport 2332 -select USB=504400379 -telnetport 2333 -singlerun -endian little -noir -speed auto -port 2331 -vd -device MIMXRT1051xxxxB -if SWD -halt -reportuseraction
-----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:      yes
Generate logfile:              off
Verify download:               on
Init regs on start:            off
Silent mode:                   off
Single run mode:               on
Target connection timeout:     0 ms
------J-Link related settings------
J-Link Host interface:         USB
J-Link script:                 none
J-Link settings file:          none
------Target related settings------
Target device:                 MIMXRT1051xxxxB
Target interface:              SWD
Target interface speed:        auto
Target endian:                 little

Connecting to J-Link...
J-Link is connected.
Device "MIMXRT1051XXXXB" selected.
Firmware: J-Link Ultra V4 compiled Oct 26 2018 12:04:46
Hardware: V4.00
S/N: 504400379
Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB
Checking target voltage...
Target voltage: 3.39 V
Listening on TCP/IP port 2331
Connecting to target...Found SW-DP with ID 0x0BD11477
Scanning AP map to find all available APs
AP[1]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x04770041)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FD000
CPUID register: 0x411FC271. Implementer code: 0x41 (ARM)
Found Cortex-M7 r1p1, Little endian.
FPUnit: 8 code (BP) slots and 0 literal slots
CoreSight components:
ROMTbl[0] @ E00FD000
ROMTbl[0][0]: E00FE000, CID: B105100D, PID: 000BB4C8 ROM Table
ROMTbl[1] @ E00FE000
ROMTbl[1][0]: E00FF000, CID: B105100D, PID: 000BB4C7 ROM Table
ROMTbl[2] @ E00FF000
ROMTbl[2][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
ROMTbl[2][1]: E0001000, CID: B105E00D, PID: 000BB002 DWT
ROMTbl[2][2]: E0002000, CID: B105E00D, PID: 000BB00E FPB-M7
ROMTbl[2][3]: E0000000, CID: B105E00D, PID: 000BB001 ITM
ROMTbl[1][1]: E0041000, CID: B105900D, PID: 001BB975 ETM-M7
ROMTbl[1][2]: E0042000, CID: B105900D, PID: 004BB906 CTI
ROMTbl[0][1]: E0040000, CID: B105900D, PID: 000BB9A9 TPIU-M7
ROMTbl[0][2]: E0043000, CID: B105F00D, PID: 001BB101 TSG
Cache: Separate I- and D-cache.

I-Cache L1: 32 KB, 512 Sets, 32 Bytes/Line, 2-Way
D-Cache L1: 32 KB, 256 Sets, 32 Bytes/Line, 4-Way
Found SW-DP with ID 0x0BD11477
AP map detection skipped. Manually configured AP map found.
AP[0]: AHB-AP (IDR: Not set)
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FD000
CPUID register: 0x411FC271. Implementer code: 0x41 (ARM)
Found Cortex-M7 r1p1, Little endian.
FPUnit: 8 code (BP) slots and 0 literal slots
CoreSight components:
ROMTbl[0] @ E00FD000
ROMTbl[0][0]: E00FE000, CID: B105100D, PID: 000BB4C8 ROM Table
ROMTbl[1] @ E00FE000
ROMTbl[1][0]: E00FF000, CID: B105100D, PID: 000BB4C7 ROM Table
ROMTbl[2] @ E00FF000
ROMTbl[2][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
ROMTbl[2][1]: E0001000, CID: B105E00D, PID: 000BB002 DWT
ROMTbl[2][2]: E0002000, CID: B105E00D, PID: 000BB00E FPB-M7
ROMTbl[2][3]: E0000000, CID: B105E00D, PID: 000BB001 ITM
ROMTbl[1][1]: E0041000, CID: B105900D, PID: 001BB975 ETM-M7
ROMTbl[1][2]: E0042000, CID: B105900D, PID: 004BB906 CTI
ROMTbl[0][1]: E0040000, CID: B105900D, PID: 000BB9A9 TPIU-M7
ROMTbl[0][2]: E0043000, CID: B105F00D, PID: 001BB101 TSG
Cache: Separate I- and D-cache.

I-Cache L1: 32 KB, 512 Sets, 32 Bytes/Line, 2-Way
D-Cache L1: 32 KB, 256 Sets, 32 Bytes/Line, 4-Way
Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0x00206742 (Data = 0x68139901)
Read 2 bytes @ address 0x00206742 (Data = 0x9901)
Received monitor command: reset
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
Resetting target
Downloading 8192 bytes @ address 0x60000000 - Verified OK
Downloading 584 bytes @ address 0x60002000 - Verified OK
Downloading 16104 bytes @ address 0x60002248 - Verified OK
Downloading 15840 bytes @ address 0x60006130 - Verified OK
Downloading 16096 bytes @ address 0x60009F10 - Verified OK
Downloading 3196 bytes @ address 0x6000DDF0 - Verified OK
Downloading 12 bytes @ address 0x6000EA6C - Verified OK
Downloading 72 bytes @ address 0x6000EA78 - Verified OK
Downloading 780 bytes @ address 0x6000EAC0 - Verified OK
J-Link: Flash download: Bank 0 @ 0x60000000: 1 range affected (65536 bytes)
J-Link: Flash download: Total time needed: 2.227s (Prepare: 0.092s, Compare: 0.551s, Erase: 0.173s, Program: 0.834s, Verify: 0.561s, Restore: 0.013s)
Writing register (PC = 0x60002054)
Read 4 bytes @ address 0x60002054 (Data = 0xF8DFB672)
Reading all registers
Read 4 bytes @ address 0x60002054 (Data = 0xF8DFB672)
Read 2 bytes @ address 0x60002054 (Data = 0xB672)
Received monitor command: exec SetRestartOnClose=1
Executed SetRestartOnClose=1
Setting breakpoint @ address 0x60002054, Size = 2, BPHandle = 0x0001
Starting target CPU...
...Breakpoint reached @ address 0x60002054
Reading all registers
Removing breakpoint @ address 0x60002054, Size = 2
Read 4 bytes @ address 0x60002054 (Data = 0xF8DFB672)
Reading 64 bytes @ address 0x600020C0
Reading 64 bytes @ address 0x60002040
Reading 64 bytes @ address 0x60002080

 

There are two things I want to understand.

 

  1. On lines 96 and 97 I find that two readings are requested at the same address (0x00206742) of 4 and 2 bytes.
    [...]
    Reading all registers
    Read 4 bytes @ address 0x00206742 (Data = 0x68139901)
    Read 2 bytes @ address 0x00206742 (Data = 0x9901)
    Received monitor command: reset
    [...]
    Addresses between 0x00200000 and 0x00217FFF are within the ROMCP (ROM Bootloader). This also includes the address 0x00206742.
    Why is the reading of a location inside the ROM Bootloader requested? Why is the reading requested with two different dimensions?
  2. After writing the flash, the program counter is written instead of issuing a reset.
    [...]
    J-Link: Flash download: Bank 0 @ 0x60000000: 1 range affected (65536 bytes)
    J-Link: Flash download: Total time needed: 2.227s (Prepare: 0.092s, Compare: 0.551s, Erase: 0.173s, Program: 0.834s, Verify: 0.561s, Restore: 0.013s)
    Writing register (PC = 0x60002054)
    Read 4 bytes @ address 0x60002054 (Data = 0xF8DFB672)
    Reading all registers
    Read 4 bytes @ address 0x60002054 (Data = 0xF8DFB672)
    Read 2 bytes @ address 0x60002054 (Data = 0xB672)
    Received monitor command: exec SetRestartOnClose=1
    Executed SetRestartOnClose=1
    Setting breakpoint @ address 0x60002054, Size = 2, BPHandle = 0x0001
    Starting target CPU...
    ...Breakpoint reached @ address 0x60002054
    [...]
    Doing so the ROM Bootloader will not run. So the FW is in a different situation than when the device is started without debugger (initialized peripheral, clocks activated, etc...)
    How can I force a reset instead of writing to the PC, so that the ROM Bootloader will run?

best regards

Max

Outcomes