The disassembly window in the debugger is interpreting the assembly as non-vle instructions when they are actually VLE instructions. I can't find a setting to force this window to interpret as VLE. The project settings are all for compiling VLE.
Target is an MPC5634M.
Was this ever resolved? I have the same symptom.
Hi Bruce,
I am not sure, if Joseph fix his problem, but I found the root cause of this issue. MMU entries affect if you see bookE or VLE instructions in the disassemble window. There is VLE bit, which could be set to 0 or 1.
Please look at the document in the attachment, which shows, how this VLE bit affect disassembly window.
So look and let me know, if it works on your side.
Regards,
Martin
Hi Martin,
Thanks for the document.
I probably should have mentioned that I'm using the MPC5643L (rather than MPC5634M), and the startup code I adopted uses TLB entry 0 to map Flash.
That said, my entry-0 has VLE=1: I checked the regPPCTLB1 entry, as well as the MAS2 word used to populate it. Just for fun, I also tried setting VLE=0 and Resume-ing, and (to no one's surprise) it crashed immediately, so we suppose that my program wouldn't have run very long with TLB VLE=0.
Do you know what program is responsible for doing the disassembly? It doesn't seem to be the CW disassembler, since changing its parameters (project Settings) doesn't seem to affect the window output. In many systems it would be a gdbserver-ish thing, but I haven't been able to find one of those.
Hi,
are you able to share your project, or at least some project which demonstrates the problem?
From my deep investigation I found, that instruction interpretation in disassembly window is dependent on MMU settings.
Regards,
Martin
Thanks for the response. I don't doubt that you found one possible cause, but it doesn't seem to
be what I'm encountering. In my case, not only is VLE=1 in the (relevant) TLB entry, my program
wouldn't have functioned at all if VLE=0.
One symptom I hadn't noticed before: Disassembly was acting correctly for the Reset code, down in
the first 4KB, but not above, i.e. the debugger was honoring the Reset TLB setting, but not the
current setting.
In my case, the trigger seemed to be executing, or rather not executing, the init script
(MPC5643L_VLE.tcl). I had moved it elsewhere in the tree, and the debugger couldn't find it. The
interesting line maps CAM0 over all of Flash (with VLE=1):
reg regPPCTLB1/MMU_CAM0 = 0xB0000008FE0800000000000000000001
When this command was not being executed, the debugger seemed to latch onto the Reset TLB setting,
whatever my code later set in the TLB. Similarly, if I (1) execute the script (2) remove the
script then (3) do a "reset" in the Debugger Shell, the TLB goes back to reset (4KB) state, but
the debugger correctly disassembles above 4KB, as though it "remembers" the command setting,
rather than what's actually in the TLB.In your test case, you were presumably executing a "reg"
command, so the effect was visible.
I don't know what's really going on inside, but this points to a workaround, an init script that
only (A) runs "envsetup" just in case (B) runs the "reg" command and (C) runs a "disassemble"
command. (Oddly, the sequence doesn't function without that "disassemble" command; I don't know why.) There
are undoubtedly refinements possible, but this lets me get back to what I was doing, and maybe
will help the OP.
----------------------------------------------------------------------------------
proc envsetup {} {
radix x
config hexprefix 0x
config MemIdentifier v
config MemWidth 32
config MemAccess 32
config MemSwap off
}
envsetup
#reg regPPCTLB1/MMU_CAM0 = 0xB0000008FE0800000000000000000001
reg regPPCTLB1/MMU_CAM0 = 0x50000000FE0800000000000000000001
disassemble 0x30000 2
----------------------------------------------------------------------------------
Hi Bruce,
thank you very much for this deep investigation. Are you able to share some example, which shows this behavior? I would like to investigate it also on my side, but I am not able to reproduce this behavior.
Thanks in advance.
Regards,
Martin
I'll see what I can come up with, but I expect that you can generate this symptom by taking any VLE-based Example and removing (renaming) the init script, so the debugger can't find it. The predicted result is that when the debugger stops at main -- after the TLB is finalized -- __startup (down in the first 4KB of Flash) will disassemble correctly, but __start (up above 0x30000 in my system) won't. I adopted my startup code from one of the Example projects so I suppose that the TLBs are set up similarly for all of them.
It "feels" as though the debugger host side is caching the TLB, and updating its cache (1) at reset (2) when a "reg regPPCTLB1/.. =" is executed, but not every time the target program halts. (The debugger also seems capable of reading memory despite the TLB settings, which is quite useful but can cause some misleading symptoms.)
For my part, disabling the init script was semi-conscious: I didn't (at the time) know how to re-connect it, but I was pretty sure I didn't want it to run anyway. My concern was that it might "paper over" any omissions in my startup code.
Hi,
could you please clarify, which CodeWarrior you use?
Regards,
Martin
Installed Products:
- CodeWarrior for MCU
Version: 10.6.4
Build Id:150416
Hi,
I have just tested the case you describe. I have created default project for MPC5634M and I chose VLE instruction set in startup wizard. As a debug probe I have used PE Micro USB Multilink.
This is what I see in debugger disassembly window:
Are you sure you chose VLE instruction set instead of BookE?
Please check the following setting in your project:
Regards,
Martin
My settings match yours.
Hi,
could you please send me the screen of your disassembly window and also screens of PowerPC compiler settings (I need to see all compiler flags)?
Regards,
Martin
Joe
Hi Joe,
from the screens you posted I am not able to tell you, what is wrong. Is it possible for you to share the project (or some simplified), which shows the issue?
Regards,
Martin
Martin,
Can you share an email address or is there a less public way for us to continue this discussion? Is there another avenue for support? I'm currently using an evaluation license while my company determines what licenses to buy so I'm not sure what support is available.
Thanks,
Joe
Hi Joe,
please at the following URL:
How to submit a new question for NXP Support
Please submit new case, I will assign it and we can continue with the support. Also you can directly attach the project to the case to save your time.
Regards,
Martin