I creating a fairly basic test device on an ARM M7 (NXP S32KXXX) MCU and debugging with Lauterbach Trace32. Basically all it does is read some ethernet frame and send out some response frames to simulate some actual hardware. I am using FreeRTOS to set some tasking to handle the in, out, and simple processing in between. Anyway, I get it up and running and it will send messages and but the headers and payload were jumbled so I went to debug it and see what I did wrong.
I get the debugger hooked in and started and it'll hit the breakpoint on my functions just fine, but the variables were showing 0, locals, stack, even global constants. The memory dump showed the same thing when correlated back the map file. The strange thing was that they didn't update even when the variables were working in the background when stepping through.
For instance I had a simple for loop that ran for some variable number of counts and the debugger would step through that for loop the right number of times, but the local index would show as being 0 the entire time. File globals, like the total loop count, wouldn't show as updating either.
The ASM even showed it using the right instructions to update the memory values, but they didn't show a change. Setting a breakpoint on write didn't trigger, either. It wasn't getting reset afterward, and at no time showed a change after the .data segment was initialized. I could use the debugger to set the value to something new, but it seemed like the running code didn't, at least visibly.
It almost seems like it's constrained to cache and never hitting memory, but I tried forcing cache flush, and I thought I didn't enable it anyway, and MPU protection should be off as well. The only thing I can think of is that FreeRTOS (non-protected config) is conflicting with the way Trace32 works (I have enabled the Trace32 FreeRTOS plugin as well). Trace32 is also not identifying the tasks and queues correctly either, though I'm not sure if that's a cause or result of not seeing updating values in what it looks for. The other thing might be using NXP S32DS and Windriver Diab to compile if that doesn't play nice with FreeRTOS or something.
At this point I have no idea what is causing the issue. I am new to this particular chip and Trace32 but I've never seen a behavior like this. Plus, everyone else around me here is similarly confused by this failure mode and they have more experience than I do.
Misc. solution attempts:
I tried different hardware for both EVB and debugger, adding various levels of optimization (was -O0), changing variables from local to global and back, defining some variables as volatile, initializing to different values (it would show it's .data value forever), adjusting memory ranges in linking, adding a dummy task that should have hogged cache, checking MPU regions and FreeRTOS configs for protected tasks. I tried forcing variable updates while running as in this question as well, but that didn't affect the result.
I did end up finding the answer after working with support and really getting into the documentation much more. The Lauterbach documentation is a bit dense and hard to parse, but with help I found the answer. I can't share any scripts directly but I will describe what ended up being a small if difficult to find change for someone like me that was unfamiliar with all these options.
The core problem was the access port not being configured in a higher access mode and so cache and memory protection were not able to be sidestepped. Attempting to setting the MPU bypass
SYStem.Optio.MPUBYPASS ONraised an error which pointed to the access class not being compatible with that function.In short, what ended up being necessary was simply changing
SYStem.MemAccessfromDAPtoAHB. This mode is able to access the memory and cache more directly. With this, everything is working great and everything has been visible to me.Note: This seems to be somewhat dependent on the specific MCU and its facilities. This isn't necessarily supported on all chips, and so this may not be a general solution, but at least if you're seeing a similar problem, access class may be a place to look. Just be sure to cross reference with your MCU documentation.
See Lauterbach documentation on info for the access class setting options (especially p34 c. 2023).