MPC5746R FRZ bit with S32DS/P&E

[losullivan]

I am int he early stages of bringing up a MPC5746R uC, using bare metal firmware. When I went to initialize the STM (with FRZ=1, ie. freeze counter on halt), I found that the timer wasn't counting when I entered a debug session within S32DS with my P&E Multilink (or Cyclone). That is, even when both cores are initialized, running and not halted, the timer wasn't counting as long as the session was started using the debugger. If i allowed the uC to start naturally, ie by simply powering it up, the STM did appear to count (as indicated by an LED). Similarly, if I turned the FRZ bit off (ie don't freeze on debug halt) I did get get the STM to count up - even in the context of a debug session. So it's behaving as if, with the FRZ bit set, the STM simply doesn't function if the uC was started with a debugger. I've tried the STM_0, doing all accesses from CORE_0 (the lockstep core), as well as STM_1 from core 1. Same result.

I conducted a similar experiment with the PIT and found the same thing, with respect to it's FRZ bit. And so i have a feeling all peripherals that have a FRZ bit are going to behave like this. The one that worries me especially would be the SWT (wachdog).

I've come across a couple of references to issues relating to MPC5xxx multicore uCs with the FRZ bit: https://community.nxp.com/t5/MPC5xxx/timer-interrupt-does-not-work-when-FRZ-bit-is-set/m-p/670199

https://community.nxp.com/t5/MPC5xxx/s32ds-hello-pll-interrupt-example-can-t-run-on-DEVKit-MPC5748

...though not as many as i would expect if there were really a known issue here. I'd expect this to be a major problem for all developers on this family of uCs, and the focus of a great many forum posts (which I'm not seeing??).

There seems to be another set of people who cant get these modules to freeze when they halt the corresponding core (ie opposite problem as me). The lauterbach manual alludes to some requirements for starting and stopping both cores simultaneously (https://www2.lauterbach.com/pdf/debugger_mpc5500.pdf p45). I can't make out whether this issue is related to mine or not.

Is what I'm experiencing expected (no activity when FRZ bit set, and debugger connected, even with core running)? If so this is a major limitation - what are others doing to get around it? If the STM 'misses' it's compare value, it will just keep up-counting until it wraps around and eventually hits it a second time (potentially a really long time, potentially missing a periodic event). Similarity the SWT would presumably always reset the uC if the core were halted (breakpoint, etc).

[PetrS]

Hi,

unfortunately timers does not work properly in Pemicro debugger if FRZ is set for multicore debug. As far as I know this is not resolved. However timers should work if the secondary cores are running or left in a reset state (uninitialized by the main core).

BR, Petr

[losullivan]

Hi PetrS,

I didn't find that the other core's state had much of an impact on the issue. I was mostly trying my experiments with the other core running, but I also tried stm_1 on core 1, with the other core (core 0) not initialized. I cleared the enable bit for core 0 in the RCHW and did not reset core 0 on mode change when I configured my clock from core 1 (re-entering DRUN mode). The STM_1 still did not upcount with FRZ set in a debug session (but with core 1 running). As soon as i cleared FRZ, it began upcounting.

-Liam