MQX 3.8 Compatibility with CodeWarrior 10.6 - Reliable Controls

[Jim_Carlson]

Hello MQX/CW team,

My customer, Reliable Controls in Canada, asked this question (they are using the MCF5225 and the MCF5271 in two projects):

We would like to update our CW 10.2 projects that are in active development to CW 10.6; and this is where we’re seeing a problem.  We have done this and everything is working except that we are having an issue debugging MQX 3.8 with CW 10.6 (https://community.freescale.com/message/463251#463251).  We see now that the CW 10.6 release notes say that it doesn’t support MQX 3.8, but we would like to find out exactly why this is and what we can do to overcome this limitation; making a couple of changes to MQX 3.8 would be preferred for us rather than moving to MQX 4.1.

To that end, could you please put me in touch with someone that can provide some information on why CW 10.6 is not supporting MQX 3.8, and specifically why we are unable to debug MQX 3.8 using CW 10.6 software breakpoints?

Thank you for any help that you can provide.

--

Regards,

Jim

[jack]

hi Jim,

The problem with illegal instruction could be caused by SW breakpoints. But I am not sure if the issue is caused by the MQX 3.8 compatibility with CW10.6. I am contacting cw development team to have a look at this issue.

It would be helpful to find the root cause if the customer can provide the project which cause the issue and the steps to reproduce the issue.

Jack

[Jim_Carlson]

Hi Jack,

Here is the project from the customer.

Thank you!

--

Regards,

Jim

[Jim_Carlson]

Hi Jack,

Here is the description of the attached demo project from the customer:

The demo project assumes a target board with 8 meg of external ram. The pyramid.txt file is used to initiate the MCF5271 for debugging and configures the session for 2 meg of flash for database (not used in this simple demo) and 1 meg of ram for execution.

The pyramid.txt file has two sections, an ISSI and a Samsung, dependent on the actual ram chip populated on the target board.

We normally build a target and debug into external ram using P&E Micros Cyclone Max interface. I normally use the MACH-ProOne_Debug_CycloneMAX_USB debug configuration which is included in the files sent. Due to MQX resource requirements I couldn’t build a version to debug into internal ram. We always debug out of external.

The app itself sets up a single task & toggles an IO point periodically. Our problem manifests itself when we attempt to debug. We can only have a single breakpoint set at any time. If we have one active breakpoint we cannot single step and the IDE will not allow us to set a second active breakpoint.

Thank you for your help!
--

Regards,

Jim

[Jim_Carlson]

Hi Jack,

Have you had a chance to look at Reliable Controls' issue?  I just received these comments from them:

We are at the point where we have to decide to upgrade to CW10.6 or stay at 10.2  Is there any update on our problems with debugging MQX 3.8 apps in CW10.6 ? https://community.freescale.com/message/464122#464122

Thank you for your help here!

--

Regards,

Jim

[mjosborne]

Hello Jim,

I just heard that our support request is being passed back to Freescale (our FAE will be unavailable for several weeks), and we would like to get this resolved.

As advised we have upgraded to MQX 4.1, but we still have issues with our MCF5271 project using CW 10.6.

It appears that there are two issues with CW 10.6 MCF5271 support (same project in CW 10.2 works fine) :

1. It always tries to program Flash (even when there is none), and this option (Always Erase and Program flash without asking) can't be disabled.

2. Software breakpoints don't work when instruction caching is enabled (generates illegal instruction exception).

We have spent a lot of time on our end trying to resolve this issue.

[evgenyerlihman]

Hi Matt,

Do you have any updates on these issues?

Thanks,

Evgeny

[Jim_Carlson · Accepted solution]

Forwarded from Jack Ye:

I got the following information from development team about compatibility:

“Both CW 10.5/MQX 4.0 are in synch and we made the decision in old CW/MQX alignment meeting that previous MQX 3.x versions would not be supported going forward. This is because we moved to a new eclipse version and the API changed.

The product manager and the engineering team created the releases notes for the releases. There is no way to get around the API changes so the issue is not just because of SW breakpoints. Hope that helps. “

Debugger team is also trying to investigate the customer application, they have some doubts regarding “external ram”, but not confirmed.

[mjosborne]

Hi Jim, my co-worker Harley has sent you an e-mail but I just wanted to update this post too with what Harley has found...

Since bringing this issue to your attention in December we have moved our project to MQX 4.1.1 in order to be compatible with Codewarrior 10.6.

However, we are now experiencing the same issue with MQX 4.1.1 / CW 10.6.

We have narrowed it down to only occurring when we have instruction-set caching enabled (on our MCF5270/MCF5271 target processor).

With caching disabled, we are able to properly use software breakpoints with CW10.6 for both our MQX 3.8 and 4.1.1 based project.

When we enable instruction caching, we encounter an invalid instruction exception when attempting to resume after halting on a software breakpoint.

The issue does not occur when using CW 10.2. Thus it seems to be more related to CW 10.6 and not the version of MQX being used.

We are using P&E Cyclone Max programmers, though I have verified the issue also occurs using a P&E Coldfire Multilink programmer.

In addition, there is another issue we have seen when using CW 10.6.

When starting a debugging session using CW 10.6, the process is greatly slowed by CW attempting to perform unwanted flash programming.

We see “Starting 3^rd party flash programming… ERR: Warning: Programming algorithm not found for this device.” appear 3 times in the console before it seems to give up and continue with the debugging process.  We are intending to debug from RAM and do not wish to program any flash when starting a debug session.

We appreciate any help you can provide for these issues.

[bryancole-b4682]

cutworth can you help with this case?

[cutworth]

Ye Jack-B36615 can help this.