Hi,
I am trying to debug a multicore example in the i.MX7ULP-EVK rev B1. I work with MCUXpresso SDK_2_9_0_EVK-MCIMX7ULP for windows anr IAR toolchain.
Debugging a simple hello world application from ram has worked fine so I tried to go a step further and try the rpmsg_lite_pingpong_rtos example.
However if I start the debug session the core does not suspend at the main() funcion. I assume it does not even reach it. Right after starting the debug session I have the following messages in hte debug log:
Wed Jul 14, 2021 16:32:04: IAR Embedded Workbench 9.10.2 (C:\Program Files\IAR Systems\Embedded Workbench 9.0\arm\bin\armPROC.dll)
Wed Jul 14, 2021 16:32:04: Loaded macro file: C:\Program Files\IAR Systems\Embedded Workbench 9.0\arm\config\debugger\NXP\iMX7ULP_M4.dmac
Wed Jul 14, 2021 16:32:04: Loaded macro file: C:\Program Files\IAR Systems\Embedded Workbench 9.0\arm\config\debugger\NXP\iMX7ULP_Trace.dmac
Wed Jul 14, 2021 16:32:04: Loaded macro file: C:\Program Files\IAR Systems\Embedded Workbench 9.0\arm\config\debugger\NXP\iMX7ULP_Common.dmac
Wed Jul 14, 2021 16:32:05: JLINK command: ProjectFile = D:\Projects\Almer_AR\InES\imx7ulp\SDK_2_9_0_EVK-MCIMX7ULP_windows\boards\evkmcimx7ulp\multicore_examples\rpmsg_lite_pingpong_rtos\iar\settings\rpmsg_lite_pingpong_rtos_imxcm4_debug.jlink, return = 0
Wed Jul 14, 2021 16:32:05: JLINK command: scriptfile = C:\Program Files\IAR Systems\Embedded Workbench 9.0\arm\config\debugger\NXP\iMX7ULP_CortexM4.JLinkScript, return = 0
Wed Jul 14, 2021 16:32:05: Device "MCIMX7U5_M4" selected.
Wed Jul 14, 2021 16:32:05: DLL version: V7.50a, compiled Jul 8 2021 18:21:11
Wed Jul 14, 2021 16:32:05: Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Wed Jul 14, 2021 16:32:05: JTAG speed is initially set to: 32 kHz
Wed Jul 14, 2021 16:32:05: InitTarget() start
Wed Jul 14, 2021 16:32:05: ***************************************************
Wed Jul 14, 2021 16:32:05: J-Link script: iMX7ULP Cortex-M4 core J-Link script
Wed Jul 14, 2021 16:32:05: ***************************************************
Wed Jul 14, 2021 16:32:05: InitTarget() end
Wed Jul 14, 2021 16:32:05: TotalIRLen = 4, IRPrint = 0x01
Wed Jul 14, 2021 16:32:05: JTAG chain detection found 1 devices:
Wed Jul 14, 2021 16:32:05: #0 Id: 0x6BA00477, IRLen: 04, CoreSight JTAG-DP
Wed Jul 14, 2021 16:32:05: DPv0 detected
Wed Jul 14, 2021 16:32:05: AP map detection skipped. Manually configured AP map found.
Wed Jul 14, 2021 16:32:05: AP[0]: AHB-AP (IDR: Not set)
Wed Jul 14, 2021 16:32:05: AP[1]: APB-AP (IDR: Not set)
Wed Jul 14, 2021 16:32:05: AP[2]: MEM-AP (IDR: Not set)
Wed Jul 14, 2021 16:32:05: AP[3]: AHB-AP (IDR: Not set)
Wed Jul 14, 2021 16:32:05: AP[4]: MEM-AP (IDR: Not set)
Wed Jul 14, 2021 16:32:05: AP[5]: MEM-AP (IDR: Not set)
Wed Jul 14, 2021 16:32:05: AP[3]: Core found
Wed Jul 14, 2021 16:32:05: AP[3]: AHB-AP ROM base: 0xE00FF000
Wed Jul 14, 2021 16:32:05: CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
Wed Jul 14, 2021 16:32:05: Found Cortex-M4 r0p1, Little endian.
Wed Jul 14, 2021 16:32:05: FPUnit: 6 code (BP) slots and 2 literal slots
Wed Jul 14, 2021 16:32:05: CoreSight components:
Wed Jul 14, 2021 16:32:05: ROMTbl[0] @ E00FF000
Wed Jul 14, 2021 16:32:05: ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
Wed Jul 14, 2021 16:32:05: ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT
Wed Jul 14, 2021 16:32:05: ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
Wed Jul 14, 2021 16:32:05: ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM
Wed Jul 14, 2021 16:32:05: ROMTbl[0][5]: E0041000, CID: B105900D, PID: 000BB925 ETM
Wed Jul 14, 2021 16:32:05: ROMTbl[0][8]: E0044000, CID: B105900D, PID: 005BB906 CTI
Wed Jul 14, 2021 16:32:05: SetupTarget() start
Wed Jul 14, 2021 16:32:05: Disabling Cortex-M4 MPU ...
Wed Jul 14, 2021 16:32:05: SetupTarget() end
Wed Jul 14, 2021 16:32:05: ResetTarget() start
Wed Jul 14, 2021 16:32:05: ResetTarget() end
Wed Jul 14, 2021 16:32:06: Hardware reset with strategy 0 was performed
Wed Jul 14, 2021 16:32:06: Initial reset was performed
Wed Jul 14, 2021 16:32:06: Found 1 JTAG device, Total IRLen = 4:
Wed Jul 14, 2021 16:32:06: #0 Id: 0x6BA00477, IRLen: 4, IRPrint: 0x1 CoreSight JTAG-DP
Wed Jul 14, 2021 16:32:07: Loaded debugee: <path to SDK>\SDK_2_9_0_EVK-MCIMX7ULP_windows\boards\evkmcimx7ulp\multicore_examples\rpmsg_lite_pingpong_rtos\iar\debug\rpmsg_lite_pingpong_rtos_imxcm4.out
Wed Jul 14, 2021 16:32:08: 203952 bytes downloaded and verified (212.11 Kbytes/sec)
Wed Jul 14, 2021 16:32:08: Download completed and verification successful.
Wed Jul 14, 2021 16:32:08: ResetTarget() start
Wed Jul 14, 2021 16:32:08: ResetTarget() end
Wed Jul 14, 2021 16:32:08: Software reset was performed
Wed Jul 14, 2021 16:32:08: Target reset
Wed Jul 14, 2021 16:32:09: HardFault exception.
Wed Jul 14, 2021 16:32:09: The processor has escalated a configurable-priority exception to HardFault.
Wed Jul 14, 2021 16:32:09: An MPU or Execute Never (XN) default memory map access violation has occurred on an instruction fetch (CFSR.IACCVIOL, MMFAR).
Wed Jul 14, 2021 16:32:09:
Wed Jul 14, 2021 16:32:09: Exception occurred at PC = 0xffffffff, LR = 0x0
Wed Jul 14, 2021 16:32:09:
Wed Jul 14, 2021 16:32:09: See the call stack for more information.
One can see that right after "target reset" a HardFault occurs.
Is there anything special that needs to be done to debug multicore applications?
Thank you for your help.
Best regards,
David
Hello,
May I ask for the steps that you are following for your test?
Also, please try by stopping at uboot and then connect using JLINK.
Best regards,
Aldo.
Can I except any help on this?
If you are looking into it but have not an answer yet that is fine, but a notification that this is beeing investigated would be nice.
Best regards,
David
Wondering if you ever got any resolution on this problem? I'm running into what I think is the same issue on an i.MX8MP with the FreeRTOS multicore demos, where it immediately his the hard fault handler. If I do a reset from within the IAR debugger, I then get to main() and can run/debug code. But a subsequent reset after code has been running hits the hard fault handler again.
FWIW, my debug log ends as follows:
Fri Dec 31, 2021 14:43:50: Software reset was performed
Fri Dec 31, 2021 14:43:50: Target reset
Fri Dec 31, 2021 14:44:11: HardFault exception.
Fri Dec 31, 2021 14:44:11: The processor has escalated a configurable-priority exception to HardFault.
Fri Dec 31, 2021 14:44:11:
Fri Dec 31, 2021 14:44:11: An instruction executed with an invalid EPSR.T or EPSR.IT field (CFSR.INVSTATE).
Fri Dec 31, 2021 14:44:11:
Fri Dec 31, 2021 14:44:11: Exception occurred at PC = 0x12ee6, LR = 0x4649
Fri Dec 31, 2021 14:44:11:
Fri Dec 31, 2021 14:44:11: See the call stack for more information.
Hi,
unfortunatly I never got to resovle this issue. The project moved to a different MCU in the end so I stoped looking into this.
Good Loock.
Bummer, but thanks. It appears to be FreeRTOS-related, as the non-multicore FreeRTOS examples do the same thing (FreeRTOS version of "hello world", etc). I've posted separately about this, we'll see if I get anywhere...