Hello,
I have a few questions regarding the debugging of a STM32H745 dual core controller.
1. Is simultaneous debugging of both cores fully supported/possible?
It works, more or less, but I noticed some problems:
e.g. sampling a variable for the timeline data graph with one Ozone instance connected to CM7, while another Ozone instance is connected to CM4, will result in zeros in the graph, and even worse, it will zero the sampled variable in memory.
In the image you can see how "dwtval_avg" (on-chip calculated average of dwtval) gets reset
![](https://forum.segger.com/index.php/Attachment/5966-1-png/?s=27d5354129cfc1d988f19c3d7b68d2116b6d3ef9)
I also had cases, where the debugger (J-link Ultra+ V5.1), lost its firmware while trying to start a debug session and needed to reload it.
![](https://forum.segger.com/index.php/Attachment/5955-1-PNG/?s=27d5354129cfc1d988f19c3d7b68d2116b6d3ef9)
![](https://forum.segger.com/index.php/Attachment/5956-2-png/?s=27d5354129cfc1d988f19c3d7b68d2116b6d3ef9)
2. what does Ozone do when I click “Download & Reset Program” and why could it fail?
e.g. right now, I cannot access the CM4, while CM7 works fine
From console:
Display All
2a. Does it reset/halt both cores or just one?
2b. Does it write something to RAM? Because the error above mentions RAMCode
2c. What could prevent the debugger from debugging? The core must be on, I guess, anything else?
2d. What is the "T-bit of XPSR" and what does this warning/info mean?
I have a few questions regarding the debugging of a STM32H745 dual core controller.
1. Is simultaneous debugging of both cores fully supported/possible?
It works, more or less, but I noticed some problems:
e.g. sampling a variable for the timeline data graph with one Ozone instance connected to CM7, while another Ozone instance is connected to CM4, will result in zeros in the graph, and even worse, it will zero the sampled variable in memory.
In the image you can see how "dwtval_avg" (on-chip calculated average of dwtval) gets reset
I also had cases, where the debugger (J-link Ultra+ V5.1), lost its firmware while trying to start a debug session and needed to reload it.
2. what does Ozone do when I click “Download & Reset Program” and why could it fail?
e.g. right now, I cannot access the CM4, while CM7 works fine
From console:
Source Code
- Debug.Start();
- Device "STM32H745XI_M4" selected.
- ConfigTargetSettings() start
- ConfigTargetSettings() end - Took 8us
- InitTarget() start
- SWD selected. Executing JTAG -> SWD switching sequence.
- DAP initialized successfully.
- Enabling debug in 'Standby', 'Stop' & Sleep mode.
- InitTarget() end - Took 21.9ms
- Found SW-DP with ID 0x6BA02477
- DPIDR: 0x6BA02477
- CoreSight SoC-400 or earlier
- AP map detection skipped. Manually configured AP map found.
- AP[0]: AHB-AP (IDR: Not set)
- AP[1]: AHB-AP (IDR: Not set)
- AP[2]: APB-AP (IDR: Not set)
- AP[3]: AHB-AP (IDR: Not set)
- AP[3]: Skipped ROMBASE read. CoreBaseAddr manually set by user
- AP[3]: Core found
- CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
- Found Cortex-M4 r0p1, Little endian.
- Cortex-M: The connected J-Link (S/N 5051*****) uses an old firmware module: V2 (current is 3)
- FPUnit: 6 code (BP) slots and 2 literal slots
- ROM table scan skipped. CoreBaseAddr manually set by user: 0xE00FF000
- I-Cache L1: 0 KB, 1 Sets, 16 Bytes/Line, 1-Way
- D-Cache L1: 0 KB, 1 Sets, 16 Bytes/Line, 1-Way
- Connected to target device.
- J-Link/J-Trace serial number: 5051*****)
- Reset: Halt core after reset via DEMCR.VC_CORERESET.
- Reset: Reset device via AIRCR.SYSRESETREQ.
- Elf.GetBaseAddr(); // returns 0x8100000
- Target.ReadU32 (0x08100000); // returns 0x4, data is 0x10000600
- Target.SetReg ("SP", 0x10000600);
- Elf.GetEntryPointPC(); // returns 0x81023CC
- Target.SetReg ("PC", 0x81023CC);
- Timeout while preparing target, RAMCode did not respond in time!
- Failed to perform RAMCode-sided Prepare()
- Verification of RAMCode failed @ address 0x24000558.
- Write: 0xE7DB4798 69236961
- Read: 0xE7DB47A5 69236961
- Download failed: J-Link reports an unspecified download error
- Elf.GetBaseAddr(); // returns 0x8100000
- Target.ReadU32 (0x08100000); // returns 0x4, data is 0x10000600
- Target.SetReg ("SP", 0x10000600);
- Elf.GetEntryPointPC(); // returns 0x81023CC
- Target.SetReg ("PC", 0x81023CC);
- Memory map 'after startup completion point' is active
- Startup complete (PC=0x08101934)
- T-bit of XPSR is 0 but should be 1. Changed to 1.
2b. Does it write something to RAM? Because the error above mentions RAMCode
2c. What could prevent the debugger from debugging? The core must be on, I guess, anything else?
2d. What is the "T-bit of XPSR" and what does this warning/info mean?
The post was edited 2 times, last by fraengers ().