I tried to run TWR-K53N512 demo in IAR-8.10, but when I opened the demo workspace, I got an "Load library error":
"C:\iar-mqx\arm\plugins\rtos\MQX\MQXRtosPluginARM.dll": the specified procedure could not be found.
However I checked that specific folder, and the file "MQXRtosPluginARM.dll" DOES exist!
So anybody got hint on this error?
This is the first that I've heard of this problem. The develop team will have to investigate it. I will update you when I have some results. Please use IAR 7.x for temp workaround.
Thank you for reporting this issue.
Do you have any further information on this issue? Are NXP actively looking into the problem?
As a company we are worried that now the MQX usage model has changed, future debugging support will only be provided on MQX 5.x. Could you clarify NXPs position, or let me know who I need to contact to get clarification.
Thanks in advance,
That is not actually a viable solution to the problem as it requires purchasing a license for MQX v5, and updating our products to now use it. I take it based on the response there is not plan to support MQX 4.2 with IAR 8.x and newer? I am sure we are not alone in choosing NXP processors at least in part because of the availability of MQX at no cost when using your processors.
This is now a GIANT GIANT MESS......
I do not think any action was taken by Freescale to address this issue even after 4 weeks (promised for 2 weeks)...Daniel Chen
IAR in the mean time upgraded IAR EWARM from v 8.10 to 8.11 and they completely dropped MQX PLUGIN, this is NOT fair !
We have projects hosted on Kinetis microprocessors using MQX and now we are forced to be in NO MAN's LAND.
I don't support this stuff anymore, but since you tagged me, I feel I should share my thoughts. Our current SDK packages do NOT support IAR 8.x yet. This is stated in the release notes.
I don't know what the official schedule is to add 8.x support, so hopefully someone more close to the SDK development team can answer that. If I had to guess, it would be the next update cycle. You have to remember that it's very hard to fit in major tool releases (I consider 8.x to be very major) to the existing schedules, so there is typically lag between the release of the new tool and support for them in software packages from most silicon vendors. We can't change our schedules to work around tool updates because we'd be constantly changing release dates. Our SDK release cycle has historically focused on predictable update cycles and rolls in tool updates as they make sense to keep our cadence.
At this point the SDK development team can try to figure out what's going on in order to give you some advice, but I don't know if they've been mandated to support IAR 8.x yet. Since the project file format appears different in the new version, the issue could be something in the project generation automation or even in IAR itself. If I were in your shoes, I would submit a question to IAR regarding this issue since they'll be much more capable of finding the root cause at this point. I'm sure every time they release a new version of the tool (especially a major one like this), they get lots of hiccups similar to what you're seeing. I remember major issues back when they went from 4.x to 5.x.
I think you are misinterpreting our discussion in this post. We are NOT talking about sdk at all, our discussion is centred around MQX TAD plugin that goes in IAR EWARM.
I've contacted IAR. Their responses include...
"I see no MQX-plug-in in 8.11.1, so in some sense it's been fixed"
">A company called Embedded Access has taken over the ownership of the
>They have started to look at the porting of the plug-in for MQX, but I
>have no information about when it can be ready."
I get the distinct impression that customers using MQX have been left high and dry. Unless willing to move over to the new improved non-free MQX model, though even that might be unsupported.
We are certainly reviewing our use of freescale/nxp, based on this lack of support. FWIW, we are also likely to ditch IAR (or at least the support element) based on this lack of continued functionality support.
I really hope NXP come up trumps and support their existing customer base, but from what I'm witnessing I suspect they will not.
Any update would be welcome.
Thanks for the information, and looks like we have to re-consider our usage of Freescale chips too, We cannot live on mercy of 3rd party who have decided to charge $6000+$3,500/year for the license.
See here: MQX™ v5 Software Solutions|NXP
A small increment in licensing would have been appropriate, MQX 4.2.2 was $0 next logical and rational step would have been to increment it to couple of hundred dollars NOT couple of thousand dollars ($9,500/year to be precise).
We have decided to drop MQX and Freescale chips altogether in our next generation of products.
Very disappointed in seeing such a radical change happen so soon and leaving customers amidst their product development cycles.
Here is my temporary solution:
* delete two .dll files under "...\arm\plugins\rtos\MQX\*.dll"
* Then you won't see those messages, and you can still compile/run program successfully!
I don't know why and whether there is any side-effect, but you can try.
I do not think that is the correct solution, that will disable MQX plugin, I will loose my debugging capabilities for STACK/HEAP/Processes/Queues/Memory usage/ Stack overflow etc etc.
It is as good as I do not select MQX plugin from IAR GUI. But I do not want to loose all that powerful capability that MQX TAD plugin provides.
Thanks for letting me know: I just tried the demo example, so have not investigated much on this issue.
Have you actually tried my solution? Here is my another observation:
* Under MQX installation folder, you will see folders like:
--- "...MQX\tools\iar_extensions\Embedded Workbench 5.x"
--- "...MQX\tools\iar_extensions\Embedded Workbench 6.x"
--- "...MQX\tools\iar_extensions\Embedded Workbench 7.x"
* And insides those folders, you will see .dll file:
--- "...\Embedded Workbench 7.X\arm\plugins\rtos\mqx\MQXRtosPluginArm.dll"
So you see, MQX package already installed the *.dll file for old IAR versions.
* If we use the *.dll from IAR-8.10 (Embedded Workbench 8.x), maybe there is incompatibility.
*But if we delete the *.dll from IAR-8.10, the *.dll file from old version can still be used even in IAR-8.10!
Just my guessing, hope somebody can clarify it.