Debug probe + S32DS: not possible to debug M7 core

[MichalMatyl]

Hello,

I set up S32DS with the NXP Debug Probe, but I work with a custom S32G2 based board and I'm experiencing issues while trying to debug code.
The code is AutoSAR based application running on M7 core and the board has primary QSPI wired to channel B instead of channel A, like I described in the other thread:

Debug probe + S32DS: not possible to flash QSPI B chip

but I don't think QSPI wiring is related to the issue I'm going to describe.

In general, I can "somewhat" debug the code, step through the code and change variables' values etc., however not for long and only in serial boot mode. But this way I'm sure that my Debug Probe + S32DS + debug configuration is proper. So I'd like to describe 3 different debugging scenarios which should highlight the issues I'm facing. I'm also attaching gdb console logs for each of these scenarios.

1. Debugging in serial boot mode

The ELF file is flashed successfully to the target and by default the debugging session stops in the main() function. From here I can step through the code and change variables' values etc. I can debug the code to the point where the Os and BswM have started as I can stop debugging in my SWC's init and cyclic runnables. The cyclic runnable period is 100ms, I resume debugging c.a. 20 times, then when I remove the breakpoint and resume again, the debug session terminates or I get "Interrupt failed" error or I end up in ErrorHook() handler.

I'm not particularly interested in the debugging issues here, because serial boot mode is not the proper one for debugging. It only shows that my Debug Probe, IDE and debug configuration is properly set up for debugging.

2. Normal mode

In normal mode the debug session doesn't even start because the Debug Probe fails to flash the ELF file with "ccs:Bus error" and "ccs:Core disabled" errors. See attached gdb log for details.

3. Start debugging session in serial boot, resume in normal mode

In this scenario I can only debug the application in the early init phase, up to the point where Os calls Os_ThreadInit() inside Os_HookCallOs_CoreInitHook(). The debug session is still active, I can suspend and resume, but alway end up in the same line of Os_HookCallOs_CoreInitHook().

---

We have a working Lauterbach setup which allows us to flash QSPI B and debug the code. Based on that I adapted S32DS debugger's python scripts for flashing as described in mentioned thread - this allowed me to flash QSPI B chip with NXP Debug Probe. But further efforts to adapt debug settings didn't bring any results. But I belive the issue here is the proper board configuration for debugging. We also have PMIC's WDG debugging mode to prevent unexpected WDG resets that might interfere with the debugger.

I noticed that the Lauterbach script for flashing and S32DS debugger's python script for flashing are basically 1 to 1 implementation, so I guess debugging configuration script could be adapted to work with the custom board as well.

Could you possibly provide such Lauterbach equivalent for S32DS ?

Best regards
Michal

[MichalMatyl · Accepted solution]

Hello.

I received a new HW sample and while setting it up I noticed the QSPI chip was re-wired back from channel B to channel A. The sample also contains a convenient add-on board with JTAG connector and some control switches, for example one labelled "power controlled by flash adapter".

I decided to try the Debug Probe with the switch active, but it didn't help much unfortunately. However I noticed I could now start a debugging session in normal mode, but it was terminated instantly. Anyway, it was somewhat more promising at this point, so I also decided to apply the PMIC/WDOG debug mode patch. With this I could now run the debug session for about 2 seconds (that's how long CAN frames were transmitted by the ECU).

Within these 2 seconds I could suspend and resume debugging, set breakpoints etc., but after 2 seconds the debug session was terminated with this familiar "ccs: Bus error" again. I couldn't figure it out, but then I recalled that 2 seconds is the time we load A53 application from M7 core. So I disabled the A53 loading (and running) and now I can debug M7 core without problems. I'm marking this thread as solved.

As I mentioned before, I use custom S32G2-based HW build with custom OSEK-based AutoSAR classic application while I have impression that S32DS is designed specifically to support NXP's development boards (e.g. fixed configuration for QSPI channel A support only). It would be great if some guides for custom HW builds setup with the Debug Probe were included in official documentation. Here's the conditions that worked for me:

1. S32DS project setup from scratch by importing the source code
2. Debug configuration set up with default settings. ELF file selected from within the project. OSEK OS awareness set. My chip is S32G233A but the configuration works also with S32G234M. Both s32g2xx_generic_bareboard.py and s32g2xx_generic_bareboard_all_cores.py initialization scripts work.
3. QSPI chip wired to channel A
4. "Power controlled by flash adapter" active, meaning both PWRON1_VR5510 and STAT_VR5510_DEBUGMODE pins pulled down.
5. PMIC/WDOG set to debug mode (via SW)
6. A53 app disabled (i.e. the app is not loaded and not run)

With these condition I cannot debug A53 core, but I'm perfectly happy with M7 core debugging. I also noticed S32DS call stack is not available (I read that's a feature in S32DS release notes) and step over doesn't work (also a feature). That limits debugging capabilities, but it's better than nothing anyway.

Best regards
Michal

[MichalMatyl]

Hi @Mehul_Patel_NXP,

Have you found some time to look into these logs ? I'd really appreciate.

Thank you in advance.

Michal

[Mehul_Patel_NXP]

Hi, @MichalMatyl ,

From what is seen in the 2nd log the debugger probe tries to read from address 0x40000200 which seems to be reserved.

But as, the access of memory regions that are not initialized may hang the M7 core and it cannot be restored without debug session restart

Access of memory regions that are not initialized may hang the M7 core and it cannot be restored without debug session restart the easiest test is to update this code line:

phg_0 = Range(0x4001C000, 0x000E4000, 'nocache')

from:

init_scripts\s32g2xx\s32g2xx_memory_regions.py

This will adjust the peripheral region to avoid the reserved area and the read from address 0x40000200 will not be propagated to CCS and the core will not be hanged.

Please can you try this accordingly, and check if any issue.

And if it is still an issue, please let us know. 

Thank you. Best regards. 

-Mehul Patel

[MichalMatyl]

Hi @Mehul_Patel_NXP,

Thank you for looking into this.

I applied the code change and indeed 0x40000200 address readout is now gone from the gdb log. Other than that, nothing has changed and "bus error" and "core disabled" errors are still there.

But I wondered how debugging works in scenario 1 if it also reads out 0x40000200 address ? So I captured the init part of gdb log in scenario 1 and I think the difference in registers' configurations could point you to the cause of this issue.

All logs and difference reports attached.

I'd be grateful if you could check that too.
Michal