pyOCD
pyOCD copied to clipboard
pyocd
Memory Transfer Fault connecting to STM32H743ZI2
I'm using Mbed studio to try and debug on a STM32H743ZI2, and it fails with a read error like:
0000860:WARNING:rom_table:Invalid coresight component, cidr=0x0
0000861:WARNING:rom_table:Invalid coresight component, cidr=0x0
0000862:ERROR:rom_table:Error attempting to probe CoreSight component referenced by ROM table entry #5: Memory transfer fault (read) @ 0xe00f0fbc-0xe00f1043
Traceback (most recent call last):
File "/home/dan/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/pyocd/coresight/rom_table.py", line 358, in _read_table
self._handle_table_entry(entry, entryNumber)
File "/home/dan/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/pyocd/coresight/rom_table.py", line 408, in _handle_table_entry
cmpid.read_id_registers()
File "/home/dan/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/pyocd/coresight/rom_table.py", line 113, in read_id_registers
regs = self.ap.read_memory_block32(self.top_address + self.IDR_READ_START, self.IDR_READ_COUNT)
File "/home/dan/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/pyocd/probe/stlink_probe.py", line 271, in read_memory_block32
return conversion.byte_list_to_u32le_list(self._link.read_mem32(addr, size * 4, self._apsel))
File "/home/dan/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/pyocd/probe/stlink/stlink.py", line 385, in read_mem32
return self._read_mem(addr, size, Commands.JTAG_READMEM_32BIT, self.MAXIMUM_TRANSFER_SIZE, apsel)
File "/home/dan/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/pyocd/probe/stlink/stlink.py", line 343, in _read_mem
raise exc
pyocd.core.exceptions.TransferFaultError: Memory transfer fault (read) @ 0xe00f0fbc-0xe00f1043
Resetting target
A minimal command that causes this is:
pyocd cmd -c reset
Repeatedly trying to reproduce this shows the fault happens at particular addresses: 0xe00f0fbc-0xe00f1043 or 0xe000efbc-0xe000f043
See logs: mbed-studio.log minimal.log
~~According to STM32H7 programming manual, there is a "Vendor-specific memory" block from 0x0000000 to 0xE0100000. There is a note that suggests naive access to this memory can cause a crash, which I suspect is the root cause:~~
~~Using the Peripheral, Private peripheral bus, or Vendor-specific memory areas can lead to unpredictable behavior in some systems. This is because the processor uses a different interfaces for load/store instructions and vector fetch in these memory areas. If the vector table is located in a region of memory that is cacheable, core must treat any load or store to the vector as self-modifying code and use cache maintenance instructions to synchronize the update to the data and instruction caches~~
~~More from the manual~~
~~There are two ROM tables on the APB-D bus. The ROM table is a CoreSight component that contains the base addresses of all the CoreSight components on the APB-D bus. These tables allow a debugger to access the topology of the CoreSight components automatically. The first table points to the second table, and to the CoreSight components located in D3 power domain: SWO, SWTF, TSG. The DBGMCU is not referenced by the table as it is not a standard CoreSight component. The table occupies a 4-Kbyte, 32-bit wide chunk of APB-D address space, from 0xE00E0000 to 0xE00E0FFC when accessed by the debugger, and from 0x5C000000 to 0x5C000FFC when accessed from the system bus~~
~~Where the system ROM table 1 shows that 0x01C to 0xFC8 is "reserved".~~
It seems PyOCD is choking on these Coresight components:
-
0xE00E3000: "SWO" (Serial wire output) -
0xE00E4000: "SWO funnel"
@flit could you take a look at this? It seems like it might be an easy one, though I don't understand Coresight enough to know.
A clean install of PyOCD master shows that the above omits an initial memory fault reading at ROM table entry 0 before the "Invalid coresight component, cidr=0x0". I have no idea what I'm looking at and am well and truly stuck.
/home/dan/Documents/pyocd_ws/bin/python /home/dan/Documents/pyocd_ws/bin/pyocd gdbserver -O connect_mode=under-reset
0003220:INFO:board:Target type is stm32h743zitx
0003257:INFO:coresight_target:Asserting reset prior to connect
0003362:INFO:dap:DP IDR = 0x6ba02477 (v2 rev6)
0003449:INFO:ap:AHB-AP#0 IDR = 0x84770001 (AHB-AP var0 rev8)
0003450:INFO:ap:AHB-AP#1 IDR = 0x84770001 (AHB-AP var0 rev8)
0003451:INFO:ap:APB-AP#2 IDR = 0x54770002 (APB-AP var0 rev5)
0003453:INFO:rom_table:AHB-AP#0 Class 0x1 ROM table #0 @ 0xe00fe000 (designer=020 part=450)
0003453:INFO:rom_table:[0]<e00ff000:ROM class=1 designer=43b part=4c7>
0003453:INFO:rom_table: AHB-AP#0 Class 0x1 ROM table #1 @ 0xe00ff000 (designer=43b part=4c7)
0003454:ERROR:rom_table:Error attempting to probe CoreSight component referenced by ROM table entry #0: Memory transfer fault (read) @ 0xe000efbc-0xe000f043
Traceback (most recent call last):
File "/home/dan/Documents/pyocd_ws/src/pyocd/pyocd/coresight/rom_table.py", line 358, in _read_table
self._handle_table_entry(entry, entryNumber)
File "/home/dan/Documents/pyocd_ws/src/pyocd/pyocd/coresight/rom_table.py", line 408, in _handle_table_entry
cmpid.read_id_registers()
File "/home/dan/Documents/pyocd_ws/src/pyocd/pyocd/coresight/rom_table.py", line 113, in read_id_registers
regs = self.ap.read_memory_block32(self.top_address + self.IDR_READ_START, self.IDR_READ_COUNT)
File "/home/dan/Documents/pyocd_ws/src/pyocd/pyocd/probe/stlink_probe.py", line 271, in read_memory_block32
return conversion.byte_list_to_u32le_list(self._link.read_mem32(addr, size * 4, self._apsel))
File "/home/dan/Documents/pyocd_ws/src/pyocd/pyocd/probe/stlink/stlink.py", line 385, in read_mem32
return self._read_mem(addr, size, Commands.JTAG_READMEM_32BIT, self.MAXIMUM_TRANSFER_SIZE, apsel)
File "/home/dan/Documents/pyocd_ws/src/pyocd/pyocd/probe/stlink/stlink.py", line 343, in _read_mem
raise exc
pyocd.core.exceptions.TransferFaultError: Memory transfer fault (read) @ 0xe000efbc-0xe000f043
0003455:INFO:rom_table: [1]<e0001000:DWT class=14 designer=43b part=002>
0003455:INFO:rom_table: [2]<e0002000:FPB class=14 designer=43b part=00e>
0003456:INFO:rom_table: [3]<e0000000:ITM class=14 designer=43b part=001>
0003456:INFO:rom_table:[1]<e0041000:ETM-M7 class=9 designer=43b part=975 devtype=13 archid=4a13 devid=0:0:0>
0003457:INFO:rom_table:[2]<e0043000:CTI class=9 designer=43b part=906 devtype=14 archid=0000 devid=40800:0:0>
0003457:INFO:rom_table:APB-AP#2 Class 0x1 ROM table #0 @ 0xe00e0000 (designer=020 part=450)
0003458:WARNING:rom_table:Invalid coresight component, cidr=0x0
0003458:INFO:rom_table:[2]<e00e3000: cidr=0, pidr=0, component invalid>
0003458:WARNING:rom_table:Invalid coresight component, cidr=0x0
0003458:INFO:rom_table:[3]<e00e4000: cidr=0, pidr=0, component invalid>
0003459:INFO:rom_table:[4]<e00e5000:TSGEN class=15 designer=43b part=101>
0003459:ERROR:rom_table:Error attempting to probe CoreSight component referenced by ROM table entry #5: Memory transfer fault (read) @ 0xe00f0fbc-0xe00f1043
Traceback (most recent call last):
File "/home/dan/Documents/pyocd_ws/src/pyocd/pyocd/coresight/rom_table.py", line 358, in _read_table
self._handle_table_entry(entry, entryNumber)
File "/home/dan/Documents/pyocd_ws/src/pyocd/pyocd/coresight/rom_table.py", line 408, in _handle_table_entry
cmpid.read_id_registers()
File "/home/dan/Documents/pyocd_ws/src/pyocd/pyocd/coresight/rom_table.py", line 113, in read_id_registers
regs = self.ap.read_memory_block32(self.top_address + self.IDR_READ_START, self.IDR_READ_COUNT)
File "/home/dan/Documents/pyocd_ws/src/pyocd/pyocd/probe/stlink_probe.py", line 271, in read_memory_block32
return conversion.byte_list_to_u32le_list(self._link.read_mem32(addr, size * 4, self._apsel))
File "/home/dan/Documents/pyocd_ws/src/pyocd/pyocd/probe/stlink/stlink.py", line 385, in read_mem32
return self._read_mem(addr, size, Commands.JTAG_READMEM_32BIT, self.MAXIMUM_TRANSFER_SIZE, apsel)
File "/home/dan/Documents/pyocd_ws/src/pyocd/pyocd/probe/stlink/stlink.py", line 343, in _read_mem
raise exc
pyocd.core.exceptions.TransferFaultError: Memory transfer fault (read) @ 0xe00f0fbc-0xe00f1043
0003460:INFO:dwt:4 hardware watchpoints
0003461:INFO:fpb:8 hardware breakpoints, 1 literal comparators
0003464:CRITICAL:__main__:No cores were discovered!
Traceback (most recent call last):
File "/home/dan/Documents/pyocd_ws/src/pyocd/pyocd/__main__.py", line 150, in run
status = cmd.invoke()
File "/home/dan/Documents/pyocd_ws/src/pyocd/pyocd/subcommands/gdbserver_cmd.py", line 190, in invoke
with session:
File "/home/dan/Documents/pyocd_ws/src/pyocd/pyocd/core/session.py", line 343, in __enter__
self.open()
File "/home/dan/Documents/pyocd_ws/src/pyocd/pyocd/core/session.py", line 461, in open
self._board.init()
File "/home/dan/Documents/pyocd_ws/src/pyocd/pyocd/board/board.py", line 85, in init
self.target.init()
File "/home/dan/Documents/pyocd_ws/src/pyocd/pyocd/core/soc_target.py", line 117, in init
seq.invoke()
File "/home/dan/Documents/pyocd_ws/src/pyocd/pyocd/utility/sequencer.py", line 208, in invoke
resultSequence = call()
File "/home/dan/Documents/pyocd_ws/src/pyocd/pyocd/coresight/coresight_target.py", line 214, in check_for_cores
raise exceptions.DebugError("No cores were discovered!")
pyocd.core.exceptions.DebugError: No cores were discovered!
Process finished with exit code 1
@jeromecoutant any insight? Are you still able to get PyOCD to work with the H743ZI2 as per https://github.com/pyocd/pyOCD/issues/719#issuecomment-548443445 ?
(Sorry… I've been away for a bit, trying to catch up now!)
The issue here is the same as #1147, and can use the same solution. It seems all H7 and F7, and some others like L4S5, require extra configuration to fully wake the target as well as prevent it from entering sleep.
You can add this code to a pyocd_user.py script and place it in the working directory from where pyocd is called, or pass it on the command line via --script=<path>.
DBGMCU_CR = 0xE00E1004 # H743 address
def will_init_target(target, init_sequence):
def set_traceclken():
target.dp.write_ap(0x00, 0x23000052) # write CSW register of AP0
target.dp.write_ap(0x04, DBGMCU_CR) # write TAR register of AP0
target.dp.write_ap(0x0C, 0x00700007) # write DRW register of AP0 with DBGMCR_CR value
init_sequence.insert_after('dp_init', ('set_traceclken', set_traceclken))
Hi
target.dp.write_ap(0x04, DBGMCU_CR) # write TAR register of AP0
I didn't test, and I am not sure about comments :-)
Maybe try: DBGMCU_CR_VALUE = 0x00670007 # D3DBGCKEN | D1DBGCKEN | TRACECLKEN | DBGSTBY_D1 | DBGSTOP_D1 | DBGSLEEP_D1 target.dp.write_ap(DBGMCU_CR_VALUE, DBGMCU_CR) # write DBGMCU configuration register
Hmmm neither of those suggestions worked. But I am able to get pyocd to connect after Stm32CubeIDE connects, so long as I don't have --connect=under-reset.
Sorry it doesn't work! I'm not sure what additional steps STM32CubeIDE is doing.
You might try changing the DBGMCU_CR_VALUE to 0x00770007. This sets DBGMCU_CR[20] TRACECLKEN in addition to the previous value (seen in the CMSIS pack debug sequence), which should theoretically fix the SWO component probe failures.
However, failing to read the component IDs for the SWO components shouldn't cause pyocd to fail to connect. It's only not seeing the core that causes the failure—this is caused by these this failures in your log above:
0003453:INFO:rom_table: AHB-AP#0 Class 0x1 ROM table #1 @ 0xe00ff000 (designer=43b part=4c7)
0003454:ERROR:rom_table:Error attempting to probe CoreSight component referenced by ROM table entry #0: Memory transfer fault (read) @ 0xe000efbc-0xe000f043
That's the Cortex-M7's main ROM table, and the first entry that it fails to probe is the core's System Control Block (SCB).
Just to double-check: are you testing with the user script and --connect=under-reset?
Also, let's make sure the user script is actually running. You can either add a print("inside set_traceclken") line just after the def set_traceclken(): (indented, like the target.dp lines). Or run pyocd with debug logging enabled (-vv) and look for the line saying "set_traceclken" task was run.
If it looks like the user script isn't being used, then add --script=<path to user script .py> to the pyocd command line.
Alright I'm getting somewhere! The address was wrong, and I have to not connect under reset (any other connect option works)
DBGMCU_CR = 0x5C001004 # H743 address
DBGMCU_CR_VALUE = 0x00700007
def will_init_target(target, init_sequence):
def set_traceclken():
target.dp.write_ap(0x00, 0x23000052)
target.dp.write_ap(0x04, DBGMCU_CR) # write DBGMCU
target.dp.write_ap(0x0C, DBGMCU_CR_VALUE) # write DRW register of AP0 with DBGMCR_CR value
init_sequence.insert_after('dp_init', ('set_traceclken', set_traceclken))
Note this setup does cause Mbed studio to crash out, I bet due to mucking with the clocks.
Does pyocd see the CPU now?
Ack! Forgot the DBGMCU address differs from the debugger versus internally. (It's not like this for other STM32.)
Try setting DBGMCU_CR_VALUE to 0x0770007. (Three 7s.)
Not sure why connecting under reset would not work. Everything seems to be different on this device! 😄 Is the pyocd log output the same as before when connecting under reset, or something different?
Also not sure what could cause Mbed Studio to crash. We're not really changing clocks, just making sure they're always enabled even when the device "sleeps" (because it no longer really goes to sleep). Is it the Mbed Studio desktop application that crashes or the Mbed OS based firmware?
Setting DBGMCU_CR_VALUE=0x0770007 doesn't seem to make a difference over 0x0700007. Both work as well and have the same issue with Mbed. According to the reference manual for this chip, the only bits that should be touched are 0x10700007.
~~It's definitely the firmware that's crashing early, and it's really early, as early as entering the function __rt_entry. It appears to always be a segfault and the location it happens appears random between runs of the same binary. It does not seem to be because of the user script; even deploying with PyOCD without debugging causes the problem. Most curiously, I read out (with STM32CubeProgrammer) and checksummed the device memory after deploying with PyOCD versus mass storage copy, and both binaries appear the same! Finally, powering down and back up does not resolve the issue; only reflashing the chip.~~
~~I think that PyOCD must be messing something up in the ST-Link when it deploys the firmware. The board I'm using is a NUCLEO-H743ZI2, which has an onboard ST-Link V3.~~
Also it seems that after flashing with PyOCD, even STM32CubeProgrammer has a hard time reading memory. At this point, I think the most likely explanation is that PyOCD is accidentally enabling some security/protection feature that is reset by mass storage copy and, whether part of the option bytes or just similar to them, it is not part of the regular memory range of the chip.
Any insights as to why --connect under-reset causes PyOCD to fail on the H743? I thought it was necessary for this chip.
Should I be trusting gdb's hard fault information if I flash the chip without a --connect argument?
It seems the runtime crash has a separate cause: https://github.com/ARMmbed/mbed-os/issues/14711
Yeah, I also thought connect under-reset was necessary in order to forcibly wake the device from sleep. It certainly is a requirement for other STM32 devices.
I just reproduced these issues on my H747 board. It has similar issues by default, as well as an on-board STLink V3. What's weird is that with the user script above, connecting works perfectly as long as connect under-reset isn't used. (This is with the default ST GUI demo firmware running.)
At this point, I'm not sure what it could be. I have a long weekend coming up, so I'll try reading the H74x RM in detail and see if anything seems like it could be causing the under-reset issue.
I don't think I've asked this before… what firmware are you testing with? While pyocd should be able to gain control under most any circumstance, the firmware may be playing a part.
Good catch with the Mbed Studio debug issue.
Forgot to answer: yes, if you see the core is in HardFault in gdb then it will really be in that state. There is no circumstance where pyocd will "forge" the XPSR register value, or where reading it from the device could result in garbage (at least in theory).
Glad you're able to reproduce it! That's a sign it's not entirely user error.
I'm using ST-LINK firmware V3J7M3 and, until now, have been using the mbed-os Blinky example (but much of the weirdness I thought pyOCD was causing is explained by the incomplete ELF file).
No, it's not user error afaict. 😄 Sorry I haven't got to reading the H74x RM… I spent all weekend working on the CMSIS-Pack debug sequence support, so user scripts like the one above won't be necessary (as long as the device's Pack has the necessary debug sequence, but most STM32 Packs do).
Fwiw, erasing and programming flash on my H747 works ok so far. However, I haven't tested with an app that puts the device in a low power mode like Mbed Blinky does.
@flit What was the address for the h747 board?
Or maybe how to I find the address?
I've done some digging on this and made a little progress but not fully fixed it. I'm using an STM32H750VBT6 which is in the same family (same reference manual). Here's my script:
DBGMCU_CR = 0xE00E1004
DBGMCU_VALUE = 0x00700007
def will_init_target(target, init_sequence):
def set_traceclken():
print("old DBGMCU_CR: " + hex(target.aps[2].read_memory(DBGMCU_CR)))
target.aps[2].write_memory(DBGMCU_CR, DBGMCU_VALUE)
print("new DBGMCU_CR: " + hex(target.aps[2].read_memory(DBGMCU_CR)))
return
def wrap(seq):
return seq
init_sequence.wrap_task('discovery', lambda seq:
seq.insert_before('find_components',
('set_traceclken', set_traceclken)
)
)
If I connect not under reset, things work just fine, and I get this output:
0001402:DEBUG:sequencer:Running task discovery
0001402:DEBUG:sequencer:Running task find_aps
0001489:DEBUG:sequencer:Running task create_aps
0001489:DEBUG:sequencer:Running task create_ap.0
0001500:INFO:ap:AHB-AP#0 IDR = 0x84770001 (AHB-AP var0 rev8)
0001525:DEBUG:ap:AHB-AP#0 default HPROT=3 HNONSEC=0
0001525:DEBUG:ap:AHB-AP#0 implemented HPROT=f HNONSEC=1
0001526:DEBUG:sequencer:Running task create_ap.1
0001527:INFO:ap:AHB-AP#1 IDR = 0x84770001 (AHB-AP var0 rev8)
0001528:DEBUG:ap:AHB-AP#1 default HPROT=3 HNONSEC=1
0001528:DEBUG:ap:AHB-AP#1 implemented HPROT=f HNONSEC=1
0001529:DEBUG:sequencer:Running task create_ap.2
0001530:INFO:ap:APB-AP#2 IDR = 0x54770002 (APB-AP var0 rev5)
0001531:DEBUG:ap:APB-AP#2 default HPROT=0 HNONSEC=0
0001531:DEBUG:ap:APB-AP#2 implemented HPROT=0 HNONSEC=0
0001532:DEBUG:sequencer:Running task set_traceclken
old DBGMCU_CR: 0x700007
new DBGMCU_CR: 0x700007
0001533:DEBUG:sequencer:Running task find_components
0001533:DEBUG:sequencer:Running task init_ap.0
0001535:INFO:rom_table:AHB-AP#0 Class 0x1 ROM table #0 @ 0xe00fe000 (designer=020 part=450)
0001537:INFO:rom_table:[0]<e00ff000:ROM class=1 designer=43b part=4c7>
0001537:INFO:rom_table: AHB-AP#0 Class 0x1 ROM table #1 @ 0xe00ff000 (designer=43b part=4c7)
0001539:INFO:rom_table: [0]<e000e000:SCS v7-M class=14 designer=43b part=00c>
0001540:INFO:rom_table: [1]<e0001000:DWT v7-M class=14 designer=43b part=002>
0001541:INFO:rom_table: [2]<e0002000:FPB v7-M class=14 designer=43b part=00e>
0001542:INFO:rom_table: [3]<e0000000:ITM v7-M class=14 designer=43b part=001>
0001543:INFO:rom_table:[1]<e0041000:ETM M7 class=9 designer=43b part=975 devtype=13 archid=4a13 devid=0:0:0>
0001544:INFO:rom_table:[2]<e0043000:CTI class=9 designer=43b part=906 devtype=14 archid=0000 devid=40800:0:0>
0001544:DEBUG:sequencer:Running task init_ap.2
0001545:INFO:rom_table:APB-AP#2 Class 0x1 ROM table #0 @ 0xe00e0000 (designer=020 part=450)
0001547:INFO:rom_table:[2]<e00e3000:SWO CS-400 class=9 designer=43b part=914 devtype=11 archid=0000 devid=ea0:0:0>
0001548:INFO:rom_table:[3]<e00e4000:CSTF class=9 designer=43b part=908 devtype=12 archid=0000 devid=32:0:0>
0001549:INFO:rom_table:[4]<e00e5000:TSGEN class=15 designer=43b part=101>
0001550:INFO:rom_table:[5]<e00f0000:ROM class=1 designer=020 part=001>
0001550:INFO:rom_table: APB-AP#2 Class 0x1 ROM table #1 @ 0xe00f0000 (designer=020 part=001)
0001551:INFO:rom_table: [0]<e00f1000:CTI class=9 designer=43b part=906 devtype=14 archid=0000 devid=40800:0:0>
0001552:INFO:rom_table: [2]<e00f3000:CSTF class=9 designer=43b part=908 devtype=12 archid=0000 devid=34:0:0>
0001553:INFO:rom_table: [3]<e00f4000:ETF class=9 designer=43b part=961 devtype=32 archid=0000 devid=380:0:0>
0001554:INFO:rom_table: [4]<e00f5000:TPIU class=9 designer=43b part=912 devtype=11 archid=0000 devid=a0:0:0>
0001554:DEBUG:sequencer:Running task create_cores
0001554:DEBUG:discovery:Creating SCS component
0001555:INFO:cortex_m:CPU core #0 is Cortex-M7 r1p1
0001557:INFO:cortex_m:FPU present: FPv5-D16-M
0001558:DEBUG:sequencer:Running task set_default_reset_type
0001558:DEBUG:sequencer:Running task create_components
0001558:DEBUG:discovery:Creating DWT component
0001559:INFO:dwt:4 hardware watchpoints
0001560:DEBUG:discovery:Creating FPB component
0001561:INFO:fpb:8 hardware breakpoints, 1 literal comparators
0001562:DEBUG:fpb:fpb has been disabled
0001563:DEBUG:discovery:Creating ITM component
0001565:DEBUG:discovery:Creating SWO component
0001565:DEBUG:discovery:Creating TPIU component
0001566:DEBUG:sequencer:Running task check_for_cores
0001566:DEBUG:sequencer:Running task halt_on_connect
0001566:DEBUG:cortex_m:halting core 0
0001567:DEBUG:sequencer:Running task post_connect
0001567:DEBUG:sequencer:Running task post_connect_hook
0001567:DEBUG:sequencer:Running task create_flash
0001567:DEBUG:sequencer:Running task notify
0001567:DEBUG:cortex_m:Setting vector catch to 0x00000001
0001572:INFO:server:Semihost server started on port 4444 (core 0)
0001598:INFO:gdbserver:GDB server started on port 3333 (core 0)
However, connecting under reset doesn't get nearly as far:
0001476:DEBUG:sequencer:Running task set_traceclken
old DBGMCU_CR: 0x700007
new DBGMCU_CR: 0x700007
0001478:DEBUG:sequencer:Running task find_components
0001478:DEBUG:sequencer:Running task init_ap.0
0001480:INFO:rom_table:AHB-AP#0 Class 0x1 ROM table #0 @ 0xe00fe000 (designer=020 part=450)
0001481:INFO:rom_table:[0]<e00ff000:ROM class=1 designer=43b part=4c7>
0001482:INFO:rom_table: AHB-AP#0 Class 0x1 ROM table #1 @ 0xe00ff000 (designer=43b part=4c7)
0001483:ERROR:rom_table:Error attempting to probe CoreSight component referenced by ROM table entry #0: Memory transfer fault @ 0xe000efbc-0xe000efff
I spent some time with the H750 reference manual and found this diagram:
There are 4 ROM tables in this chip, 2 in the Cortex-M7 itself and 2 in the outside-the-core debug infrastructure. Here, pyocd is trying to parse the Cortex-M7 tables, specifically the "Cortex-M7 PPB ROM table" at 0xE00FF000 to 0xE00FFFFC. The first component in that table is the SCS at base address 0xE000E000.
It doesn't surprise me that trying to read the SCS while the core is in reset would fail (if I'm interpreting this right)... I'm not sure what should be happening here, though. @flit any ideas?
#1213 fixes part of this. The other issue is that creating the CortexM component also reads from registers that are inaccessible during reset, in order to determine if there's an FPU and if so, what type: https://github.com/pyocd/pyOCD/blob/6ce26c7d66f7b9d811e0db0e4dd5f5555b8c104f/pyocd/coresight/cortex_m.py#L377-L406
Hiya. Sorry for the slow replies.
Fyi, my primary method of resolving this is that I've been working on CMSIS-Pack debug sequence support. It's mostly implemented, but not fully integrated yet. However, it does invoke the Unlock Debug sequence, which happens to fix this problem for the H743 (at least in the cases I've tested) by configuring DBGMCU.
You're welcome to try it out: https://github.com/flit/pyOCD/tree/feature/debug_sequences It's not guaranteed to work! Any suggestions or improvements are welcome, of course. 😄
#1304 fixes a related issue, where the debug probe would remain locked after a memory transfer fault, preventing the GDB server thread from being able to use the probe at all.
What is the recommended path forward on this?
@flit that branch link is dead.
