CW 10.1, MPC5675K, PE NEXUS ML, slow operation

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

CW 10.1, MPC5675K, PE NEXUS ML, slow operation

915 Views
jhansen
Contributor I

Just got a MPC5676K-EVB with a PE NEXUS Multilink interface.

Eclipse based CW 10.1, running on Windows XP (SP3).

I created and compiled a minimum application for flash. All this works fine and is fast.

However, starting a debug session takes about 5 minutes.
This is way too long, I would have expected about 5-10 seconds, at most (which is what I get on ARM targets with other tools).

Trying with a version in RAM didn't make things much faster, still took several minutes for the debug session to start.

Anyone having the same issues?


Any solution for this?


 

Labels (1)
0 Kudos
7 Replies

398 Views
BlackNight
NXP Employee
NXP Employee

Hi,

here are a few things to check:

- host machine memory: it should be 2 GB of RAM. I had a 1 GB machine, and with other applications running together with eclipse (FireFox, Open Office, and eclipse) the machine was using beyond 1 GB of RAM, thus going very slowly

- check the JTAG/BDM clock speed: this is inside the debug configuration > Remote System > Connection: I had it set to 500 kHz, and setting it to 1 MHz was improving things a lot

- don't have too many projects open in eclipse workspace: just have the ones open you really need, as otherwise eclipse carries on a lot of background (indexer, etc) information.

- finally, there is an issue with changing IP addresses of your host: not sure if this is your case, but I was switching frequently between different IP addresses while debugging: e.g. from a wired network to a wireless network and as well into a VPN network. Eclipse somehow still used the 'old' address, which resulted in timeouts, making debugging really, really slow. So if your machine is changing the IP address of the network and it is slow, make sure you restart eclipse.

 

Hope this helps,

Erich

0 Kudos

398 Views
CarlFST60L
Senior Contributor II

I have basically the same problem with Multilink, CW10.1, Win7, 52259demo board. It far to slow, I have logged in, found this post, written this and posted and its still going!!! WHAT A JOKE

0 Kudos

398 Views
CarlFST60L
Senior Contributor II

Hi,

 

Thanks for the reply!

 

Its now taking 1:20 with all the above points changed (saved 20seconds). This is still over 3 times longer than CW7.2!

 

My PC is pretty hectic, high speed SSD, 8G DDR3, i7 2600 @ 3.4G, Win7 64bit with a Win7 x86 VM with half of all the recourses) so processing power shouldn't be much of an issue, it certainly has not been for the last couple of years on slower hardware on XP and CW7.2!  I also run an x86 XP machine on a crazy server that a company I work for built, the machine is out of this world fast, but it still takes over a minute. This machine I can use for bench marking as I have CW7.2 on it for some older projects, and there is light years between the CW10.1 and CW7.2 in download speed with the same Multilink programmer.

 

Also, even though I have unticked all the box's for subsequent downloads, it still takes 1:20!! It should take a couple of seconds like CW7.2 as it should not be programming flash or loading RAM, just set and run!? This is not very important, but clearly there is something messed up from CW7.2 ro CW10.1...

 

Also, CW10.1 debugger will NOT program data located in RAM address from your S19, CW7.2 does i.e. If you want some test data in RAM, or to use your debugger to move some initialized data from RAM to external flash/nvm devices, you can no longer put it in RAM space of your S19 and use software to detect the data and move it to external DSP/EEPROM/FLASH chips as a 'first time with debugger attached' option. I have since written an uploader to do this, but it cost me a couple of days on something that worked in 7.2.

 

My list of "things that don't work properly or at all" in CW10.1 over CW7.2 is getting VERY long... I am starting to think CW10.1 is a pile of poop *hides*

 

0 Kudos

398 Views
BlackNight
NXP Employee
NXP Employee

Hi,

yes, the machine you have is much more powerful than mine (5 years old).

But I learned that 1 GB of RAM was not enough the hard way, and now with 3 GB it is much better.

 

The thing about the S-Record is something I have forwarded internally. Just curious: you flash the S19 file (instead of the elf) in the target task? If you could share/upload that S19 file, then engineers could look at it, otherwise they should be able to reproduce what you say.

 

Another thing I missed in the list of things you could do to improve speed:

disable the 'verify' operation in the target task (which should be set up for you and the 52259).

Open the target task assoziated with your debug/launch configuration and disable it. This should cut down the time too.

The other thing is: usually I download things once, but debug it more than once.

For this I have the target task disabled in the debug/launch configuration, and do the flash programming 'externally' with the target task standalone.

If you cannot follow what I mean: let me know and I'll describe the steps in more details.

 

BK

0 Kudos

398 Views
CarlFST60L
Senior Contributor II

Hi,

 

I have gone to "Debug configurations > Debugger > Download" and ticked the box "Perform Standard Download" then turned off every option, and it still downloads and verifies on every launch!!! This proves that those box's do NOTHING at all!!! (or something is overriding it like the "Execute tasks" option...

 

As soon as I untick the other box "Execute Tasks" then it doesn't do the download at all , it just goes straight to debug in a few seconds, (even though I ticked all the box's again, just not varifiy). It seems like 'perform standard download' screen is COMPLETELY ignored!! The "Execute Tasks" is the only thing that actually controls the download, and this cannot be edited? well I cannot see any way to edit this...

To me it seems that the 'execute task' option is not looking at the "perform standard download" options at all, it just does its own thing..? Or is there another place that you tell it not to verify?

 

The only other settings I have found point to

${MQX_ROOT_DIR}/lib/m52259demo.cw10/bsp/dbg/m52259demo.cfg

${MQX_ROOT_DIR}/lib/m52259demo.cw10/bsp/dbg/m52259demo.mem

These files appear to be of no help.

 

Regarding the S19 program, I am not fussed in working on this, it was easier to find a work around than jump hoops with the guys looking after the service request I had in.

0 Kudos

398 Views
BlackNight
NXP Employee
NXP Employee

Hello,

just to be sure: this is about using the V2 52259, with OSBDM, and I assume that you use a FLASH (not RAM) target, right?

Yes, part of it is in "Debug configurations > Debugger > Download".

Here you have to have the 'perform standard download' unchecked.

Standard download means that the debugger directly writes to the target (without flash programming, so this option is useful only for RAM targets). So have it unchecked.

 

In above setting page, you should have 'execute tasks' checked. This executes a kind of script (e.g. to erase the flash, program, verify, etc). You should have there a target task listed (maybe named MPC52259_FLASH or similar), with the 'first' and 'subsequent' option set. As this is a special script file (with extension .ttf for 'target task file'), remember that file name.

 

In oder to edit that target task script file, there is a special view for this. Open it with the Window > Show View > Debug > Target Tasks (if not already open). In that view you can see the above target task (usually it is under Root > AutoFlash).

Double click on the file, which opens the editor for it (in our case: "ColdFire V234 Flash Programmer Task").

There you can disable the 'verify' option.

 

See attached screenshot which should make the thing pretty clear (I hope).

 

BK

 

0 Kudos

398 Views
CarlFST60L
Senior Contributor II

Thanks BlackNight, its great to have your help! I might have to put you on speed dial ; )

 

 

I had previously turned off the verify flash in this section, however, the verify RAM writes (top right) was ticked, so I removed this and reduced the total time to launch from 1:40 down to 40 seconds. That's a lot less Angry Birds time between burns : )

 

I will do a compare on Monday in the office with CW7.2 and CW10.1 to see what the exact difference in launch time is, it certainly feels a lot better now with everything configured properly.

 

If your interested in just how big this project is, here is one of the products (all done in CW + FSLMQX + MCF52259)

http://www.suretek.com.au/LinkClick.aspx?fileticket=kECIhGKmUIg%3d&tabid=255

 

0 Kudos