uTaskerConvert hangs up

[TomM]

Hi all,

I'm trying to move my project (MCF52258) from CW 7.2 to CW 10.5 and have run into a snag.  I've searched and found answers to most of the issues encountered but the final step is evading me.  I've added a post-build step to run a batch file for converting to a downloadable binary file.  Only thing is that when the routine runs uTaskerConvert, the program hangs and Windows (7-64bit) opens a dialog box stating that uTaskerConvert.exe has stopped working.  I verified in a DOS window that the paths specified are correct and in fact I've tested the command manually in a DOS window and it hangs there too.  The only other thing I can think of is I'm not generating the correct form of binary file.  I selected "Generate Binary Image" and did not select "Generate Raw-Binary Image".  As an aside, I'm also having trouble getting the P&E USB ColdFire Multilink to flash the device or start a debug session.

Any suggestions would be appreciated.

[mark]

Hi Tom

Did you check the CW10.x guide here? http://www.utasker.com/docs/KINETIS/uTasker_CodeWarrior10.pdf
Form uTaskerV1.4.3 M522XX - 14.03.2011 there is a CW10.x project included, which could also be used as reference for a port.

Check that you are using the latest utaskerVonvert: http://www.utasker.com/forum/index.php?topic=1445.0
The maximum code size was increased, in case this is the issue.

Otherwise, if you send me the bat file that you are using (rename to .txt to avoid filter problems) and the code that you are converting I can check it out.

Regards

Mark

[TomM]

Hi Mark,

I did check out your CW10.x guide as I moved the project and it was very helpful.   Also, I was using V1.6 of utaskerConvert, so I updated.  Unfortunately that did not change the results.  uTaskerConvert is still reported as crashing by W7.  I've attached a text file with the commands used to invoke combine and convert along with the crash details from the dialog box.  I'll send the *.bin file in a private email for you to take a look at.

Thanks!

[mark]

Hi Tom

I think that I see the problem.

You are combining uTasker_boot.bin with uTaskerV1-4.elf.bin as first step.
The problem is that these are not raw binary file but are MOTOROLA binary files. The result is uTaskerHVC_APP.bin, which is a mixture of two MOTORLA binary files with a block 0xff joing them.

Everything goes fine in the uTaskerConvert step until this area of 0xff is hit and then the attempt to interpret it causes wild results and a crash.

Initially I wondered whether it was a tactic in the MOTOROLA binary format that could insert 0xff so I attempted to just copy all 0xff until a non-0xff was encountered and then start with the header interpretation again. Although this is possible there is risk involved in case the number of 0xff between the areas were to be small and not guarantee detection of it.

Therefore I suggest using uTaskerConvert first on the two input files before then combining them. The the final conversion step will be working directly with a binary input and so not have this difficulty. The utility was adapted due to the CW behavior as seen from the release notes to V1.6:

Version V1.6 14-05-2011
===================

Added capability to convert Motorola binary to raw binary output. This is useful for CodeWarrior binary output
which can otherwise not be used directly as a code image - after the conversion the content is in raw binary format
and so suitable for general binary program use.

User "uTaskerConvert uTasker_BM.bin raw.bin -b"

Regards

Mark

[TomM]

Hi Mark,

I'll try that tomorrow, but I'm wondering why the CW7.2 files could be combined before converting?   

On a related note, I mentioned I was having problems flashing with a USB Multilink.  I found a thread on FreeScale where someone reported the same issue with an MFC52259.  Seems they fixed it by creating a project from scratch instead of importing from a CW 7.2 project.  So even though I started from your CW 10.xx project, I gave it a try.  Amazingly, from the PE project, I can program flash and debug in RAM.  Although, the debugging doesn't seem to stop at breakpoints in RAM.?  Anyway it's progress. 

Thanks

Tom

[mark]

Tom

I also asked myself why the pre-conversion was not required with CW7.
It may be due to the fact that the boot loader doesn't get MOTOROLA coded but only the application part. I say that CW10 was chopping the binary in to many small packets (typically 0xc7 bytes in length if I remeber correctly). I don't remember such small packets and so I could imagine that the boot loader uses to fit into one and so was left as raw binary.

In any case I do remember 'having' to convert files from CW10.

Regards

Mark