change to k20dx256z 100mhz processor in bsp, CW10.2, MQX 3.8.1

cancel
Showing results for 
Search instead for 
Did you mean: 

change to k20dx256z 100mhz processor in bsp, CW10.2, MQX 3.8.1

Jump to solution
926 Views
Cdn_aye
Senior Contributor I

We built a new bsp & psp based on the twrk20d72m using the board support package porting guide, and that works... as far as compiling without errors. 

 

But we need to use the k20dx256z 100mhz processor and I cannot find any of the header files for the k20 100mhz processor to build the correct MQX libraries. Do we have to manually create these files? This would be a massive task as far as I can see. In the sales info on the FSL web site it says clearly that the k20 100mhz is MQX supported but we can't find any files or documentation on how to implement this specific processor. I have the porting guide and we used that to build a new bsp structure in mqx, but the guide AN4287 only ports the board, it does not say how to change to a new processor.

 

Thanks for the help.

 

1 Solution
324 Views
Cdn_aye
Senior Contributor I

Mark,

 

Yes we got this to work, but there was a long and arduous road to getting this to work.

 

First off do not bother cloning a bsp, psp and the middle ware directories from mqx. That will serve no purpose. You can do all that once you have gotten the whole system stiched together.

 

Here are the steps we did.

 

1) we used the k20d256, this is not the correct processor. You can't use any of the k20 bsp files in mqx. The mcg does line up.

2) you must use the k40dx256. Just make a backup copy of the whole mqx directory and don't bother changing any of the names. Work directly with the k40dx256 files

3) if you are using middleware systems like, usb, mfs and so on you will have to generate a wizard based template project inorder to get all the legion of linkages to libraries correct. We tried the acedemic approach of cloning a bsp into a new name, then changing all the linkages. We got a multitude of errors missing references and so on. I would recommend going back and making your clone of the system after you get the basic project working.

4) the template project you must generate must be based on the mqx broad project, twrk40dx256. You should build an empty project template but include the middleware code base you need. This will set the linkages correctly

5) for the k20dx256, mqx 3.8.1 and 3.8.0 generates incorrect code for the mcg module. The debugger will hang waiting for the clock to sync. It never does. The code is wrong.

6) we built a Processor Expert project without mqx, loaded that and verified that we could hit a breakpoint in the code. This we could do.

7) take the code from cpu.c in PE find the section that has the mcg.

8) go into the user_config.h and make sure that the LCD driver is turned off. This is the difference between the k20 and k40

9) switch back to the mqx IDE, go to the sources directory created by mqx in the build directory, ie....\Freescale\Freescale MQX 3.8\mqx\build\cw10\bsp_twrk40x256\Generated_Code\, patch in your code for the cpu.c you got from PE

10) rebuild the bsp, psp, middleware etc

11) rebuild your project, .... add code etc.

 

Where we still have a problem is in the middleware for the USB, we can't get it to run. The task traps to the bit bucket and we don't know why.

 

It has taken several weeks to get to this point working with the mqx development group, and support.

 

If you are using the USB MFS and get it to work, I would also appreciate some feedback. We are in a time problem now for production and don't have this working. Our code base is being ported from the 51jm128 CF1 and works under mqx 3.8.1, so this is not new untested code. But we can't get past the mqx problems as yet.

 

Regards

 

Robert Lewis 

 

I will attach our cpu.c file.

View solution in original post

8 Replies
324 Views
tsxer
Contributor II

Robert,  have you received any response on this?  Have you made any progress you would be willing to share?  I also will need to port a Kinetis MQX 3.8.1 BSP to a K20DX256Z.

 

Any help or pointers would be appreciated.

0 Kudos
325 Views
Cdn_aye
Senior Contributor I

Mark,

 

Yes we got this to work, but there was a long and arduous road to getting this to work.

 

First off do not bother cloning a bsp, psp and the middle ware directories from mqx. That will serve no purpose. You can do all that once you have gotten the whole system stiched together.

 

Here are the steps we did.

 

1) we used the k20d256, this is not the correct processor. You can't use any of the k20 bsp files in mqx. The mcg does line up.

2) you must use the k40dx256. Just make a backup copy of the whole mqx directory and don't bother changing any of the names. Work directly with the k40dx256 files

3) if you are using middleware systems like, usb, mfs and so on you will have to generate a wizard based template project inorder to get all the legion of linkages to libraries correct. We tried the acedemic approach of cloning a bsp into a new name, then changing all the linkages. We got a multitude of errors missing references and so on. I would recommend going back and making your clone of the system after you get the basic project working.

4) the template project you must generate must be based on the mqx broad project, twrk40dx256. You should build an empty project template but include the middleware code base you need. This will set the linkages correctly

5) for the k20dx256, mqx 3.8.1 and 3.8.0 generates incorrect code for the mcg module. The debugger will hang waiting for the clock to sync. It never does. The code is wrong.

6) we built a Processor Expert project without mqx, loaded that and verified that we could hit a breakpoint in the code. This we could do.

7) take the code from cpu.c in PE find the section that has the mcg.

8) go into the user_config.h and make sure that the LCD driver is turned off. This is the difference between the k20 and k40

9) switch back to the mqx IDE, go to the sources directory created by mqx in the build directory, ie....\Freescale\Freescale MQX 3.8\mqx\build\cw10\bsp_twrk40x256\Generated_Code\, patch in your code for the cpu.c you got from PE

10) rebuild the bsp, psp, middleware etc

11) rebuild your project, .... add code etc.

 

Where we still have a problem is in the middleware for the USB, we can't get it to run. The task traps to the bit bucket and we don't know why.

 

It has taken several weeks to get to this point working with the mqx development group, and support.

 

If you are using the USB MFS and get it to work, I would also appreciate some feedback. We are in a time problem now for production and don't have this working. Our code base is being ported from the 51jm128 CF1 and works under mqx 3.8.1, so this is not new untested code. But we can't get past the mqx problems as yet.

 

Regards

 

Robert Lewis 

 

I will attach our cpu.c file.

324 Views
Cdn_aye
Senior Contributor I

Ok, I have just found a major fatal flaw in our system. This method allowed us to check our in house design board for the k20dx256, but the pins are wrong for all the pinouts between the k40 and k20. We had received this recommendation from the Support group dealing with the SR.

 

What I listed above will help you verify the design, if you are using your own processor board... up to the clock, powersupply, mcg and so forth. The port pins are all wrong...

 

This is why our usb does not work. I should have had the sense to check this on my own. I accepted the solution without checking the hardware match. This served the purpose of getting the board up, now we have to go the route of trying to build a working bsp.

 

I will keep you informed. This will probably be a mixture of Mark and my methodology. I will look more carefully at the k20d and see if I can use that code base for the bsp after copying in our cpu.c

 

The reason we switched from the k20d was we could not get the mcg to sync;\

 

 

Regards

 

Robert Lewis

0 Kudos
324 Views
Cdn_aye
Senior Contributor I

We have a working bsp now. If there is a further interest, I can update with the details.

Regards

Robert Lewis

0 Kudos
324 Views
jerrystoner
Contributor III

I'm going through this right now and I'm finding it's just as painful as you're saying. I'd love more details!

0 Kudos
324 Views
Cdn_aye
Senior Contributor I

Do a search on my posts and this may help. The starting point is to use the twrk40dx256 bsp; do not change anything in the mcg module. We had to do that because we started with the k20d bsp which was a mistake. I would suggest leaving all the naming as is, do not bother with renaming or trying to clone a k20 bsp, that will not yield anything but grief.

My understanding is that mqx 4.0 will have a way to build your own bsp. You will not be tied to the prebuilt bsp's from the mqx team. I think mqx 4.0 is imminent if not already out.

Regards

Robert

0 Kudos
324 Views
MarkP_
Contributor V

Hi,

The header file MK20DZ10.h is found in:

C:\Freescale\CW MCU v10.2\MCU\lib\wizard_data\ARM\DataBase\derivatives

Copy this into your bsp-directory, example:

C:\Freescale\Freescale MQX 3.8\lib\twrk40x256.cw10\bsp

This is the generated directory used at build, the original location is in mqx/source/...

 

Copy/change the line in bat-file in C:\Freescale\Freescale MQX 3.8\mqx\build\bat

for new header file, example:

copy /Y ..\..\..\mqx\source\bsp\twrk40x256\twrk40x256.h .

 

Change in user_config.h:

//#define MQX_CPU                 PSP_CPU_MK40DX256Z

#define MQX_CPU                 PSP_CPU_MK20DX256Z

 

This new header is included in kinetis.h:

 #elif   (MQX_CPU == PSP_CPU_MK20DX128Z) || \

         (MQX_CPU == PSP_CPU_MK20DX256Z) || \

         (MQX_CPU == PSP_CPU_MK20DN512Z)    

 #include "MK20DZ10.h"

 

~Mark

 

324 Views
Cdn_aye
Senior Contributor I

Mark,

 

can you elaborate on your solution please?

 

You are using the twrk40dx256 as your example, what do we do if we are using the 100 pin LQFP k20dx256? Where do we account for this change?

 

Which bat file are you editing, is this the bsp_twrk40x256.bat file? Or should we be looking at another.

 

MQX does not have any twr boards for the 100mhz processor, and it builds the templates from the twr boards, what do you do to work around this?

 

Thanks

 

Robert

0 Kudos