Codewarrior Debugger Disassembly is not VLE

cancel
Showing results for 
Search instead for 
Did you mean: 

Codewarrior Debugger Disassembly is not VLE

758 Views
josephperrin
Contributor I


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.

Labels (1)
0 Kudos
16 Replies

295 Views
brucemckenney
Contributor III

Was this ever resolved? I have the same symptom.

0 Kudos

295 Views
martin_kovar
NXP Employee
NXP Employee

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

0 Kudos

295 Views
brucemckenney
Contributor III

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.

0 Kudos

295 Views
martin_kovar
NXP Employee
NXP Employee

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

0 Kudos

295 Views
brucemckenney
Contributor III

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

0 Kudos

295 Views
martin_kovar
NXP Employee
NXP Employee

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

0 Kudos

295 Views
brucemckenney
Contributor III

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.

0 Kudos

295 Views
martin_kovar
NXP Employee
NXP Employee

Hi,

could you please clarify, which CodeWarrior you use?

Regards,

Martin

0 Kudos

295 Views
josephperrin
Contributor I

Installed Products:

- CodeWarrior for MCU

  Version: 10.6.4

  Build Id:150416

0 Kudos

295 Views
martin_kovar
NXP Employee
NXP Employee

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:

pastedImage_0.png

Are you sure you chose VLE instruction set instead of BookE?

Please check the following setting in your project:

pastedImage_1.png

pastedImage_2.png

pastedImage_3.png

Regards,

Martin

0 Kudos

295 Views
josephperrin
Contributor I

My settings match yours.

0 Kudos

295 Views
martin_kovar
NXP Employee
NXP Employee

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

0 Kudos

295 Views
josephperrin
Contributor I

pastedImage_0.png

pastedImage_1.png

pastedImage_2.png

pastedImage_3.png

Joe

0 Kudos

295 Views
martin_kovar
NXP Employee
NXP Employee

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

0 Kudos

295 Views
josephperrin
Contributor I

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

0 Kudos

295 Views
martin_kovar
NXP Employee
NXP Employee

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

0 Kudos