CodeWarrior for MCU中的主题 Re: Codewarrior Debugger Disassembly is not VLE

Codewarrior Debugger Disassembly is not VLE

josephperrin — Thu, 28 Jul 2016 17:33:50 GMT

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.

Re: Codewarrior Debugger Disassembly is not VLE

martin_kovar — Mon, 01 Aug 2016 08:38:20 GMT

Hi,

could you please clarify, which CodeWarrior you use?

Regards,

Martin

Re: Codewarrior Debugger Disassembly is not VLE

josephperrin — Mon, 01 Aug 2016 12:03:46 GMT

Installed Products:

- CodeWarrior for MCU

Version: 10.6.4

Build Id:150416

Re: Codewarrior Debugger Disassembly is not VLE

martin_kovar — Mon, 01 Aug 2016 12:58:44 GMT

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

Re: Codewarrior Debugger Disassembly is not VLE

josephperrin — Mon, 01 Aug 2016 17:28:03 GMT

My settings match yours.

Re: Codewarrior Debugger Disassembly is not VLE

martin_kovar — Tue, 02 Aug 2016 05:26:45 GMT

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

Re: Codewarrior Debugger Disassembly is not VLE

josephperrin — Wed, 03 Aug 2016 15:39:32 GMT

Joe

Re: Codewarrior Debugger Disassembly is not VLE

martin_kovar — Thu, 04 Aug 2016 07:01:33 GMT

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

Re: Codewarrior Debugger Disassembly is not VLE

josephperrin — Thu, 04 Aug 2016 12:56:03 GMT

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

Re: Codewarrior Debugger Disassembly is not VLE

martin_kovar — Thu, 04 Aug 2016 13:02:28 GMT

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

Re: Codewarrior Debugger Disassembly is not VLE

brucemckenney — Mon, 19 Sep 2016 21:09:18 GMT

Was this ever resolved? I have the same symptom.

Re: Codewarrior Debugger Disassembly is not VLE

martin_kovar — Tue, 20 Sep 2016 11:34:27 GMT

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

Re: Codewarrior Debugger Disassembly is not VLE

brucemckenney — Tue, 20 Sep 2016 16:12:35 GMT

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.

Re: Codewarrior Debugger Disassembly is not VLE

martin_kovar — Wed, 21 Sep 2016 12:29:29 GMT

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

Re: Codewarrior Debugger Disassembly is not VLE

brucemckenney — Wed, 21 Sep 2016 20:07:36 GMT

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
----------------------------------------------------------------------------------

Re: Codewarrior Debugger Disassembly is not VLE

martin_kovar — Thu, 22 Sep 2016 10:57:51 GMT

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

Re: Codewarrior Debugger Disassembly is not VLE

brucemckenney — Thu, 22 Sep 2016 13:19:51 GMT

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.