Coldfire debugger does not resume after initial break, register values missing

[mikegr]

I am recently responsible for maintaining a codebase with a coldfire V2 target (MCF52277) that includes MQX RTOS 3.0.1 and is compiled/linked using Codewarrior 7.1.1.  I am debugging remotely using the PEmicro Coldfire Multilink debugger, USB-ML-CFE.  I want to run the debugger from flash.  I have been successful at flashing the code and starting the debugger to the first breakpoint.   When the code breaks, I am able to see the symbolic C code and the live variable names and contents.  However, when I try to either step through the code or "run" to the next breakpoint, the debugger hangs at "Program X is executing.  Chosse break from Debug Menu to stop it".  when I choose break, Codewarrior seems to no longer be attached to the BDM module.  I also noticed that when the code breaks, all of the register values are zero.  I see these under "View->Registers->PEMICRO_USB->Program.elf->Thread0x0".  I have checked over the configuration files many times and do not see any issues for this hardware set. Any ideas?  this would be of great help.

[TomE]

Does MQX enable the Core Watchdog?

It may be triggering when you break and would therefore be resetting the CPU. There should be a setting somewhere to let you disable it and debug - it may be a configuration or build option.

Type "mqx watchdog" into the Search. This looks interesting and gives pointers:

Does MQX use the hardware watchdog

Tom

[mikegr]

I dug into the MQX source and found an instance where the MQX does enable the watchdog and services in in the systick routine.  This did not solve my problem, however, because it seems my problem is even more fundamental (see response above).  I need to be able to successfully communicate with the BDM over USB first.  The strange thing is that the Code Warrior Flash Programmer utility does work over the PEmicro Coldfire Multilink debugger, USB-ML-CFE.  I don't know why I can not successfully download my program to internal RAM.  Any thoughts? 

[JimDon]

Try opening the case and remove the jumper inside. The case will pop open.

[mikegr · Accepted solution]

All,

Thanks for your help.  I found the issue and it solved all of the strange behavior that I noted in this thread. It is a compatibility problem with CodeWarrior 7.1 and the PG&E Multilink driver (see step 6 below).  Freescale technical support acknowledged that CodeWarrior 7.1 is not compatible with the latest PG&E multilink drivers.  I am using classic code warrior on a Windows 7 machine so I need to install two different versions of the Multilink driver, one for native windows and one for the virtual machine.   Here are the steps.

1) Open PG&E Multilink Device case and move jumper to pins 2-3 (don't use clock).

2) Install the latest P&E Multilink Driver on Windows 7.  Windows 7 requires a later version of the driver to function with the multilink.  Go ahead and use the latest driver (I used 11).

3) Install XP Mode (Virtual Machine)

4) Install CodeWarrior 7.1 on Virtual Machine (XP Mode).  It will not install/run in native Windows 7.

5) Plug in Multilink USB device to PC.  Attach Multilink USB device to Virtual Machine. This will cause the Multilink USB device to turn off (bug?)

6)  Remove Multilink USB from PC USB port and plug it back in.  The virtual machine will recognize the device and the hardware wizard will ask to install the driver.  Install the older version of the P&E Multilink driver that is shipped with the device (in my case I used driver version 9 for the USB-ML-CFE rev C device)

[mikegr]

I removed the jumper inside the PE multilink (so that it not using the CLK).  It programmed a bit slower, but otherwise the behavior was the same.  The Flash Programmer is able to write to flash, but not read (verify).

[JimDon]

Have you tried creating a new default project and debugging it?

[mikegr]

I created a default project to debug from internal ram.  In this case, I press the debug button, the following error occurs "Memory Write Verify Failure: Memory write to address 0x346aef6 failed to verify: Expected value:

0x8000400 Actual Value:0x0."  There is an existing thread that describes a similar problem with CodeWarrior and PE Micro USB-ML-CFE multilink.

https://community.freescale.com/thread/51908

Evidently, BDM works with USB 1.1 but not USB 2.0.  The problem is that I can not get my modern PC to run USB 1.1

Any thoughts? thanks!

[JimDon]

What kind of BDM is it? Because I can tell you if it is a P&E that thread is just plain wrong. A P&E works just fine with USB 2.0. In fact I have run a Multi-Link on a a USB 3.0 port.

[mikegr]

Thanks for your help.  I am using P&E USB Multi-link.  I am able to use the CodeWarrior Flash Programmer and my multilink to successfully program an image, so things do seem to work at the USB level.  I have noticed the following behavior which may help understand root cause:

1) When using Flash Programmer, If I select "Verify Target Memory Writes", then programming fails with the message "Can not read target memory at location: 0x80000500. Please make sure that the chip selects are properly configured. The CWPP response code is: 0x0."

2) When using Flash Programmer, If I uncheck "Verify Target Memory Writes", then my image is successfully burned to Flash.  However, if I press "Verify", the following error occurs... "Verify Failed: 10 data mismatches occur."

The image is actually programmed fine.

It seems like something is incorrect with the .cfg  file, but I can't find a manual that explains how to set these for a custom board (non-eval board).  It is almost as if the read operations are trying to read from internal RAM rather than flash (internal RAM is memory mapped to 0x80000000 whereas Flash is mapped to 0x00000000)

[mikegr]

This shows when programming failed because "verify write" (during programming)  was selected.

======================================================================
=== Execute: Program
=== Timestamp:  Wed Apr 10 14:57:01 2013
=== Flash Device:   S29GL032M(R4,R6)
=== Flash Organization:   2Mx16x1
=== Flash Mem Start Addr: 0x00000000
=== Flash Mem End Addr:   0x003FFFFF
======================================================================
Informing other connection clients that the target is being 'clobbered'.
Loading Flash Device Driver at: 0x80000000
Flash Programmer: Can not read target memory at location: 0x80000500. Please make sure that the chip selects are properly configured. The CWPP response code is: 0x0.

Timestamp:  Wed Apr 10 14:57:03 2013

[mikegr]

This shows when the Verify command failed after programming was successful.

======================================================================
=== Execute: Verify
=== Timestamp:  Wed Apr 10 14:59:18 2013
=== Flash Device:   S29GL032M(R4,R6)
=== Flash Organization:   2Mx16x1
=== Flash Mem Start Addr: 0x00000000
=== Flash Mem End Addr:   0x003FFFFF
======================================================================

Uploading 0x00010000 bytes starting from address 0x00000000
Data Mismatch at address: 0x00000000. Expected: 0x80. Actual:   0x00
Data Mismatch at address: 0x00000001. Expected: 0x02. Actual:   0x00
Data Mismatch at address: 0x00000006. Expected: 0x04. Actual:   0x00
Data Mismatch at address: 0x0000000A. Expected: 0x04. Actual:   0x00
Data Mismatch at address: 0x0000000B. Expected: 0x3E. Actual:   0x00
Data Mismatch at address: 0x0000000E. Expected: 0x04. Actual:   0x00
Data Mismatch at address: 0x0000000F. Expected: 0x3E. Actual:   0x00
Data Mismatch at address: 0x00000012. Expected: 0x04. Actual:   0x00
Data Mismatch at address: 0x00000013. Expected: 0x3E. Actual:   0x00
Flash Programmer: 10 data mismatches occur.

Verify command complete
Timestamp:  Wed Apr 10 14:59:21 2013

[mikegr]

I will break the Flash Programmer log file into three parts. Starting here.  This shows when the programming operation was successful (verify write was turned off):

======================================================================
=== Execute: Program
=== Timestamp:  Wed Apr 10 14:57:39 2013
=== Flash Device:   S29GL032M(R4,R6)
=== Flash Organization:   2Mx16x1
=== Flash Mem Start Addr: 0x00000000
=== Flash Mem End Addr:   0x003FFFFF
======================================================================
Informing other connection clients that the target is being 'clobbered'.
Loading Flash Device Driver at: 0x80000000
Flash Driver Buffer is at:   0x80001800
Flash Driver Buffer Size is: 0x0001E800
Done

Initialization Command Succeeded

Programming 0x00010000 bytes of Target Memory at 0x00000000
Programming 0x00010000 bytes of Target Memory at 0x00010000
Programming 0x00010000 bytes of Target Memory at 0x00020000
Programming 0x00010000 bytes of Target Memory at 0x00030000
Programming 0x00010000 bytes of Target Memory at 0x00040000
Programming 0x0000584C bytes of Target Memory at 0x00050000
Programmed total of 0x0005584C bytes

Program Command Succeeded
Timestamp:  Wed Apr 10 14:58:01 2013
: -------------------------

Verifying file C:\Firmware_101\NAL01_Application\Output\Pegasus_Flash.elf