TWR-K20d72M MQX/Codewarrior install issues

[cwpaynter]

I've just got a TWR-K20D72M board, and am trying to get my build environment working.  Two issues have come up:

1) When you download the "BSP for TWR-K20D72M" patch for MQX, it tries to install in its own directory "C:\Freescale\Freescale MQX 3.8 TWRK20D72M" rather than the c:\Freescale\Freescale MQX 3.8 directory where everything else is installed.  Is it safe to redirect it to the "standard" directory where MQX is already installed? Or does it have to live in its own directory.  Also, do you need to manually integrate MQX again into CW 10.2?

2) There is a Service Pack for codewarrior  to support the K20 parts, but when I try to update the CW installation, some of the .jar files are reported as not found,  This happens whether I try to update from the website or from a local downloaded copy of the Service Pack.

cheers,

Chris

[c0170]

Hello cwpaynter,

1. it is completely safe to install it into the MQX directory. What do you mean manually integrate MQX into CW10.2?

2. This question should be asked in CodeWarrior section. Which CW are you using? I'll download the update from the site and test it.

Regards,

MartinK

[cwpaynter]

Thanks for the reassurance Martin, I will repost the CW portion to the CW forum.

My question about the manual integration stems from the 1.0.0 update to CW 10.2.  It apparently has some incorrect batch files which cause the MQX integration to fail, and there are new batch files which you need to use and manually call to integrate MQX 3.8 with CW 10.2.  10.2 was released before 3.8, so doesn't know how to integrate MQX 3.8 support.   If your first assertion is right, that it's OK to install the TWR-K20 MQX patch into the existing MQX directory, I would assume it's probably not necessary to do the manual integration again....  

cheers,

Chris

[Cdn_aye]

In the properties of the build you will see that the "Linked Resources" points to the correct directory for MQX, which is the tower patch. As I am sure you know, you have to rebuild the libraries.

We also have the TWR-K20d72M and have found that the example MQX i2c driver fails part way through.  In fact we have found a lot of problems with the system so far.

We also have an inhouse board using the k20 and the MQX i2c driver fails on that as well. So we are casting about with FSL support trying to find a piece of code that works to get a reference point. The GPIO functions work but that is as far as we can get on either system.

I have asked FSL support for  a working project but have not heard back as yet. If I remember correctly we could not get the mqx and PE wizard to build a working baseline project. The compiler errored out as well.

I would be interested in your results as well.

Regards

Robert

[Cdn_aye · Accepted solution]

Just to check, I went back and created a project just with mqx, no PE, empty project using the wizard. It will not compile.

here is what I get; totally hopeless.... I will post this as a new post and see if we can get any help

Description Resource Path Location Type Link failed. k20    C/C++ Problem mingw32-make: *** [k20.afx] Error 1 k20    C/C++ Problem Overflow in segment: rom from section: .main_application Segment reserved size is: 0x00007be0 -- Overflow of: 0x00001928 k20    C/C++ Problem illegal #pragma k20  line 49, external location: C:\Freescale\Freescale MQX 3.8 TWRK20D72M\lib\twrk20d72m.cw10\psp\mqx.h C/C++ Problem Symbol calloc multiply defined in libc_Thumb_LE_v7M.a(alloc.o        ) and bsp_twrk20d72m_d.a(cw.o           ) Ignoring the definition in libc_Thumb_LE_v7M.a(alloc.o        ) k20    C/C++ Problem Symbol exit multiply defined in libc_Thumb_LE_v7M.a(abort_exit.o   ) and bsp_twrk20d72m_d.a(cw.o           ) Ignoring the definition in libc_Thumb_LE_v7M.a(abort_exit.o   ) k20    C/C++ Problem Symbol free multiply defined in libc_Thumb_LE_v7M.a(alloc.o        ) and bsp_twrk20d72m_d.a(cw.o           ) Ignoring the definition in libc_Thumb_LE_v7M.a(alloc.o        ) k20    C/C++ Problem Symbol isgraph multiply defined in libc_Thumb_LE_v7M.a(ctype_aeabi.o  ) and psp_twrk20d72m_d.a(io_util.o      ) Ignoring the definition in libc_Thumb_LE_v7M.a(ctype_aeabi.o  ) k20    C/C++ Problem Symbol isupper multiply defined in libc_Thumb_LE_v7M.a(ctype_aeabi.o  ) and psp_twrk20d72m_d.a(io_util.o      ) Ignoring the definition in libc_Thumb_LE_v7M.a(ctype_aeabi.o  ) k20    C/C++ Problem Symbol malloc multiply defined in libc_Thumb_LE_v7M.a(alloc.o        ) and bsp_twrk20d72m_d.a(cw.o           ) Ignoring the definition in libc_Thumb_LE_v7M.a(alloc.o        ) k20    C/C++ Problem

[cwpaynter]

Robert, this is interesting, I will try to duplicate your results, as I'm basically in the same boat - trying to get something, anything to work as a starting point for developing my real project.  I have since uninstalled all the K20 stuff, and am working with the K60 board, but am not clear that that's working either.  Some code compiles, and I can create and run a barebones project, but have yet to see a working MQX project on either K60 or K20.  I'll re-install the K20 MQX patch and see what I get.

Did you also have a problem with the 1.0.1 service pack for CW 10.2?

cheers,

Chris

[Cdn_aye]

Hi

I did a long post on our results but it seems to have gone into the bit bucket.

In short we have not had any success with either the k60 or k20 projects for the tower that are included in the install. That is apart from the simple GPIO functions. So far the I2C driver fails in the example project for the k60 and we can't use the wizard to generate a working empty mqx non-pe or mqx + pe project for the k20.

One thing that Kojto did point out was that the wizard build for our k20 was defaulting to RAM. We changed that to FLASH but we still get one fatal link error and several warnings about pragmas that we didn't change or touch in anyway. The project will not build. You change to FLash from Ram by going into the build manager.

The only system we got to work from the wizard was a non-mqx, system using PE. That ran the gpio correctly but the i2c driver failed. I will post if we get a working system.

[cwpaynter]

After 4 days of messing around, I have given up on the Codewarrior toolchain.  IAR was able to compile/debug all the K60 demos, including the MQX ones that I tried.  Will be moving to the K20 board shortly, and am hopeful that I'll be able to start coding my application this week.

Chris

[Cdn_aye]

I can completely relate. We have more than a few days, we have weeks of dealing with these problems.

When we first looked at IAR a few months ago the sales people promised great support, Kinetis with PE and mqx then when a more senior person looked into it, and was sorry saying 'we don't have this quite yet'. And it faded away.

If mqx is important to you and PE on the Kinetis, make sure that is written into the PO. You probably know this but you can't get the USB stack on anything but MQX at present. There is a version coming for PE but it is still in the works as far as I know.

For some reason all the best intentions turn into ' did we say that??' after the check is cashed. Especially stress test the MQX i2c carefully if that is important to you. We have found that there are timing issues under mqx. The ACK can get missed and the whole sorry lot hangs with no explanation. This was acknowledged by FSL development and is supposed to be fixed in 3.8.1 which is due out any day now. I know I am repeating myself here...

I might also look into IAR again if this doesn't get solved soon; we are running out of time and the window for our product is closing.