Has anyone had success porting MQX to a K61FX512

[Jeronimo479]

We are struggling to find all the definitions needed for a port of the MQX board support package to a K61FX, the one that has flex memory.

Wayne

[friederschrempf]

Maybe someone got any further with K61 and MQX. This would help a lot.

See my questions here: MQX on custom K61 Board

Thank you!

[Cdn_aye]

we have just finished a port from a CF V1 51JM128 to the MKK20dx256. It was razor blade sandwich... to put it mildly.

There are statements on the FSL site about how easy it is to go from a tower bsp in mqx to a custom bsp ... ie which processor that freescale markets in the millions, but we went through every level of Freescale support and the highest levels of the company and we could get no help; we were also told that MQX was a complimentary product (free) and FSL does not support custom bsp's. Every suggestion failed. Eventually we found a way through but it took months.

Write what you are doing and I will update you on where we ran into trouble and how we found a way through. Which processor, what functions etc. You may be lucky and it switches over without a hitch if the bsp & psp align exactly, but if you are using a different package and processor there are some serious misinformation in the documentation for the packages.

Regards

Robert Lewis

[Jeronimo479]

We had several starts on this project. I used AN4287, "MQX Board Support Package Porting Guide" to create a board support package for a customized TWR-K53N512 to do a proof of concept. That worked, so I was building confidence.

We acquired a TWR-K60N512 and expanded our scope.

We built a prototype pcb based on the K61Fx512VMD12, and I tried to create a BSP based on the TWR-K60N512. I changed all the memory settings that were relevant to the Flex Memory aspect. I had many macros that weren't defined, but through various sources, I got those nailed down. I was able to load the code onto our target, but when I step through the code, it looks like low_level_init.c (the right one) is never called. The code at "low_level_init:" sets R0 to 1, then returns. The calling code then checks the return code, and jumps back to start.

[Cdn_aye]

Ok, we had similar experiences.

Here is the starting point. I am assuming you are using mqx 3.8.1

A major change was done in mqx from 3.8.0 to 3.8.1, the Processor Expert (PE) component for the cpu was added to all the kinetis builds. Great concept but not correctly implemented. In a PE project you pick the processor family, the processor and the package. You can change processors by changing cpu components... simple. But with the mqx bsp builds you can pick a processor but not the package. This is a fundemental error that misled us completely. We wanted to use the k20dx256, we were told by the MQX development team, FE, TSE and many others to use the twrk20d72. Seems reasonable. Wrong bsp totally. We had to use the k40dx256.

So by using the k20d72 twr bsp, the core was completely wrong. The mcg would not sync, nothing worked except in free run mode for the clock. The usb was dead, i2c failed etc.... it took a lot of time to figure this out because we had an inhouse board, and no way to validate the design. Was it the board or was it our software or was it the mqx system or cw? Furthermore because we used the wrong reference design we had capacitors on the xtal that should not have been on the k20dx part. Another reason the mcg would not sync.

Eventually it was found that the core we needed was the k40 and what needed to be done was to turn off the LCD driver in the user_config.h. We did that but then the cw tools set showed completely wrong information in the component inspector and cpu target views... all the pins are wrong. This is because the twrk40dx256 bsp is built for a BGA 144 package. We were using a 100 pin, LQFP package. This mess is a result of a narrow world view of which cpus the mqx team decides to build against. There is no documentation on this; Freescale has not provided any as of this date. Further more if you follow the guide to cloning a bsp, you are wasting your time. This will accomplish nothing. All this does is make a duplicate copy of the bsp and psp leaving the original alone. Do an incremental backup, restore the original if you need it and ignore that the naming of the cpu being wrong. You will save yourself a world of torment for paths and modules that are wrong or missing.

So the starting point is probably really simple if you do not get pulled off course in misinformation from the toolset and appnotes. Find a core that mqx has built against that is a super set or identical. Turn off the components if any, that you are not using in the user_config.h. Do not clone the bsp, psp or anything else. Make sure that you can load the mcg and test that it does not hang, then go on to the middleware. If you are using middleware (usb, mfs etc) build an empty project with these components added. Do not use PE components apart from the cpu which you are forced to use. These will make a mess of the driver structures and are only partial implementation in some of the key components like the FlexTimer. This procedure will put all the correct paths into the project. Get that to load and make sure you can schedule a task and that the mcg still works. Then start adding your code a layer at a time.

We had to do a complete uninstall and then re-install of cw10.3 and mqx 3.8.1. I would strongly suggest you do this, with all the updates. After working with support and various resources throughout FSL and even the company that provides support to FSL for mqx, since Jun, our system would not bulid or load or run properly. You may not be in that position, but if you have muddled about in the mqx directories I would start from a known good starting point. We have been using cw10.3 before the recent public release. C10.2 had only a partial implementation of our processor, the bsp project was missing critical files. The update was a patch and fixed some of that. CW10.3 has all the latest files and we have encountered no problems.

The key is making sure you have a correct bsp and ignoring the misinformation, you can't change that.

Regards

Robert Lewis

[Jeronimo479]

I recently "upgrade" from MQX 3.8.0 to 3.8.1 hoping that the K61FX would be one of the boards added to the support list. No luck.

We are using IAR EWARM, since I pounded on eclipse and code warrior with little to no help from Freescale for 3 weeks, before I threw in the towel and jumped ship to IAR, a company I am more familiar with.

I will try your advice, but there are no similar processors to start from. :smileysad: An IAR rep suggested I start from the supported PSP_CPU_MK60DF120M or PSP_CPU_MK60DX256Z.

Thanks Again,

Wayne

[cavebiker]

Has there been any progress with this MQX to K61 port?

I tried the same thing earlier this week but I started with MQX for the K70 tower. I was told from Freescale that the K70 is the closest thing to the K61 because of the more complex Multipurpose Clock Generator (MCG) they share. Anyway, I had no luck, I got hung up on configuring the MCG in the startup code.

Any ideas on this topic would be great.

Thanks & cheers

[Cdn_aye]

H

This is the first place that the problems appear, in the MCG module. But there is a simple solution. The code base for the clock generator comes from PE.

Build a project **WITHOUT** MQX, go to the bsp_init module and cut out the code that runs the MCG. Put that into your MQX bsp module. Right now you are probably failing on the lock sync for the clock. Same thing we found. Once you get the mcg to lock you can at least deal with the remainder of the port. I am just leaving at this moment so I don't have the time to go through and find you the exact module to change but it is simple; just look in the debugger where it hangs, then make that change above in your mqx source, rebuild everything and retry.

The other way to get a working clock module is to build with just Device Initialization. Load that system to your board and check that it works. Do this without mqx of course. This code is actually also a PE component generator.

So the starting point is to get the clock working on your board apart from MQX to get a gold standard, then splice your code into MQX and continue from there. It is all doable, but very misleading because the pins will be named wrong if you have a different package... etc as I pointed out above.

All the best

Robert

[cavebiker]

Excellent, I will try this. It make sense and sounds simple enough.

Thanks Robert

Cheers,

Tom

[Cdn_aye]

We looked into that as well. It won't work. The one that might work but is very expensive is Keil, look into their system with their own middleware products. Again I believe it is a lot more money, but don't opt for the MQX version or you are back in the same predicament.

The problem is, is that IAR has a great toolset, but look more carefully into the underlying support and you will find that IAR distrubutes the FSL MQX built packages. They just modify the build scripts to work with their compilers. We tried that route twice, lots of promises and when it came down to the legal obligation, they didn't deliver because they were only delivering what FSL provides them. And they clearly stated that they would be dependant on FSL support for the bsp packages.

Here is another option that I freely admit I know only in theory because I am just starting to look further into a possible port. FreeRTOS and PE ...I have had years of experience with Processor Expert and I love it! PE has always worked well when it was not befouled by mqx.

There is a site you might consider that is run by someone in Freescale, that provides a PE component for freeRTOS, USB, MFS and many other systems. That would remove the requirement to use pre built mqx systems and the PE code always works (again in my experience). Again I stress that although I know the people internal to FSL that strongly support Erich's work and he has substantial credibilty, I have personally not had time to even build one of these projects. But from what I have seen of Erich's expertise and site, you will have a higher chance of getting this to work than with MQX unless you are doing something really off main street.

Checkout this link, mention that I sent you.

Processor Expert | MCU on Eclipse

Regards

Robert Lewis

[c0170]

Hello all,

@Robert : thanks for your information and sharing your experience with porting.

@Wayne Tailor:  You are only starting with IAR and portin K61FX. It was not added because I am not aware of any tower kit assembled with that MCU. Could you please share also with community your progress and highlight any problems in future development.

New community provides wiki pages, it would be really helpful and I bet appreciated if you share it with us, that certainly would help to overcome some issues you have had so far. Or come up with suggestions :smileywink:

Regards,

MartinK