┬ÁTasker Forum

┬ÁTasker Forum => ┬ÁTasker general => Topic started by: Genisuvi on October 25, 2018, 03:19:49 PM

Title: Last CodeWarrior version using uTasker 1.3v
Post by: Genisuvi on October 25, 2018, 03:19:49 PM
The project in which I'm working is an industrial applicaction project based on based on coldifre (mcf52259) and it's built using uTasker v1.3 with an old codewarrior version (5.9; although when you click in help button you can read: CW DS for CF Arch 7.2) some time ago.

Currently this CW IDE version is installed in a computer within windows XP OS. But debugging has never worked; the IDE hangs. And XP Ws is totally obsolete, as you know, out of official support.

I would like to install a newer CW version in a computer with windows 10, loading the whole application files, creating the project, being able to compile files and make the fw bin files with the minimum code modifications. So, porting the project.

I know that last versions of CW are not supporting uTasker v1.3, so they may be using the v1.4. But I would like to know if here is anyone who knows what is the last CW version compliant with uTasker 1.3v using the same MCU. I don't need the newest CW version, but some version newest than CW5.9 could be fine to check if debugging is possible, also running out of windows XP operating system.

I was trying to find more information about this kind of question and I also was trying to contact someone in uTasker project, but its web seems to be disabled and contact emails too. I don't know if uTasker project is stopped or I was visiting the wrong link.

Any information will be apreciate and it will be helpful.

Best regards.
Title: Re: Last CodeWarrior version using uTasker 1.3v
Post by: mark on October 25, 2018, 11:26:16 PM

You can try adding the content of the attached zip file "Coldfire_V2_CW10_project.zip" to the root directory of your uTaskerV1.3 project (that is the directory which contains \Applications \uTasker, \Hardware, etc.). This should allow you to import your project into CodeWarrior 10.
Also add the content of the second attached zip file "CodeWarrior_M522XX_CW10.zip" to the folder "\Applications\uTaskerV1.3", or your own application location (it supplies linker scripts and is the location used for output objects).
Then you should change any paths that you find which reference uTaskerV1.4 to uTaskerV1.3 or your own location.
If all works out you will then be able to build the project (make sure the correct processor and linker script is selected in CW10).
The following overview may be helpful: http://www.utasker.com/forum/index.php?topic=14.msg30#msg30

The other possibility is to use the uTaskerV1.4 version and put your application into its \Applications directory. uTaskerV1.4 contains also the CW10 project so you should be able to build yours with it. V1.4 is more or less backward compatible with V1.3. See http://www.utasker.com/forum/index.php?topic=1310.msg5300#msg5300 for a few details.

I am not aware of any problems with the email addresses but I see that you had also problems sending to my person address, with the error message that "Relay Access was denied" for all. Your company also contacted me at the same address to inform me of this (without problems) which suggests that the difficulty is related to your email account settings. I think the relay access denial occurs when you use a different output server to send messages from than the one that you account is attached to and some servers may not allow this or the destination will reject it.

The uTasker project is now 14 years old and still includes Coldfire V2 support in its project but this tends to be used only rarely for maintenance of legacy projects. After 2011 most Coldfire users switched over to Kinetis parts instead.



Title: Re: Last CodeWarrior version using uTasker 1.3v
Post by: Genisuvi on October 26, 2018, 09:50:18 AM
I'm so sorry Mark, I just copied a msg tried to be sent before. The email problems refered last line should not be posted. It's solved. The emailing problem was detected in my company email account configuration.

Thank you very much for your quick step guide. I hope it works. I will try to follow your steps.

I agree with you. I 'm also think that one of the solution to avoid future obsolescences is the hardware migration. But it could take more things and work into account: if there is a newest mcu that matches with our current mcu, pinout rerouting pcb, pinout new code configurations and new registers to be writen, peripheral control modifications, functionality testing, etc.. However, I think it will be a point in which this will become the only solution that allows the fw production maintainance, furthermore if Nxp production quit off the micro someday. So It's requires some analysis before, I'm go to start to win some bits of time trying the first quick solution.

Best regards.
Title: Re: Last CodeWarrior version using uTasker 1.3v
Post by: mark on October 26, 2018, 09:17:22 PM

As long as you can still get the Coldfire parts (and at a reasonable price) you can continue maintaining the product with the original firmware.

Sometimes (which seems to be happening at the moment with some older lines) a design in of a new part can't be avoided (eg. the original ones are no manufactured any more and no more reliable stock can be found). The natural migration for the Coldfire V2s are to Kinetis (but beware that there is no part with internal Ethernet PHY) and this is very easy when the product already uses uTasker since the application / hardware interface is highly compatible. Existing Coldifre projects can often be ported to Kinetis within a few hours without much need to get to know the Kinetis details. Pin for pin compatibility is usually not possible, so some HW modification is needed though.

Semiconductor manufactures tend to guarantee supply during 10..15 years, which gives a period where supply can more or less be relied on. In practice products are often still manufactured after this time and so a route to update should be incorporated in the general engineering cycle. At the moment of writing it is becoming almost impossible to source Luminary or ST Micro STR92x parts and so there is a wave of product upgrades where these were used.

The uTasker project (being independent) has always had the goal of intensively supporting certain parts but still keeping the application open to the use of different processors. Whereas products developed using semiconductor libraries become very locked in to the manufacture due to the fact that quite details knowledge of the chips and their HW application interface are needed, or reliance on certain code generation tools are present, when the chips gets old and their prices spiral it is difficult to escape due to the high engineering cost/risk involved to move to completely new libraries. uTasker developments can be moved efficiently and cheaply (no lock in) when this situation arrives or when better supported alternatives (also from other manufacturers) are identified, or when supply chain (lead times) makes it necessary to make a change.