I have the smaller slower version of the MK22F chip set on my custom board the MK22F12810 chip. I'd like to get a USB stack running on this chip, but there isn't a usb platform build for this chip. I've successfully used the FRDM-K22F board and ran a simple keyboard hid usb application. Is there a way I can modify the MK22F51212 platform, so I can build and run the same keyboard demo on the MK22F12810 chip? Or is there another approach I should be doing to get this kind of application running?
Hey Mark,
I haven't used utasker yet. Can I get a little more information on how this would work? I have the KSDK 1.3 and my assumption would be that I just need to figure out how to build a USB library that's compatible with this chip.
-Brendan
Hi
In the uTasker project you just enable the define USB_INTERFACE and the class (or classes) that you want (eg. USE_USB_CDC and how many interfaces, USE_USB_MSD, USE_USB_HID_MOUSE, USE_USB_AUDIO etc.) and you have a complete operating project for any Kinetis part with USB (KL, KV, K etc.). It is fully integrated and you can even add USB-RNDIS TCP/IP operation by simply enabling USB_CDC_RNDIS.
It is designed for professionals who require immediate and proven operation for fast reliable product completion, complete product operation simulation without porting worries or IDE dependencies. It doesn't require libraries to be built and its integrated USB class and drivers are compatible with all Kinetis parts.
Regards
Mark
Mark,
uTasker doesn't have a project for the chip I'm talking about MK22F12810. Is there a compatible project that I should select?
-Brendan
Brendan
NXP specifies using the FRDM-K22F
http://www.utasker.com/kinetis/FRDM-K22F.html
or the TWR-K22F120M
http://www.utasker.com/kinetis/TWR-K22F120M.html
for developments aimed at K22F128 100MHz parts.
Therefore it is best to select the FRDM_K22F target and then adjust its configuration to suit the final chip.
The open source uTasker version doesn't have full K22F128 100M support but it is very easy to adapt.
#define FRDM_K22F
1. Specify the speed to be 100MHz max.
#define KINETIS_MAX_SPEED 100000000
2. Since the chip has much less SRAM reduce the heap size, eg
#define OUR_HEAP_SIZE (HEAP_REQUIREMENTS)((12 * 1024) * MEM_FACTOR)
3. In app_hw_kinets. adjust the Flash and RAM sizes:
#define SIZE_OF_FLASH (128 * 1024) // 128k FLASH
#define SIZE_OF_RAM (24 * 1024) // 24k SRAM
4. It will be necessary to edit kinteits.h so that the SRAM addressing is correct by adding (at the appropriate location)
#elif defined KINETIS_K22 && defined KINETIS_K_FPU && (SIZE_OF_RAM == (24 * 1024))
#define RAM_START_ADDRESS (0x20000000 - (8 * 1024)) // SRAM L is 8k and is anchored to end at 0x1ffffffff
// SRAM H is the remainder of RAM size and is anchored to start at 0x20000000
5. You will need to use also a linker script file that matches.
For example use K_128_16.ld and modify two lines
SRAM (wx) : ORIGIN = 0x1fffe1f0, LENGTH = 0x00006000-0x1f0
__SRAM_segment_end__ = 0x20003fff;
to increase form 16k to 24k SRAM
The USB is compatible.
These are the (main) differences between the K22F512 120MHz and K22F128 100MHz
K22F128 has 2 SPIs, no USB-CD, no FTM3, no CMT, but has an I2S. There are only 4 DMA channels available.
All (available) interrupts are compatible so as long as non-existent channels are not attempted to be used all should be fine.
If you want to tune a little more exactly (shouldn't be really necessary) you can add/adjust these in kinetis.h
#elif defined KINETIS_K22
#if ((SIZE_OF_FLASH == (512 * 1024)) || (SIZE_OF_FLASH == (256 * 1024)) || (SIZE_OF_FLASH == (128 * 1024)))
#define UARTS_AVAILABLE 3
#else
#define UARTS_AVAILABLE 6
#endif
#elif defined KINETIS_K22
#if ((SIZE_OF_FLASH == (512 * 1024)) || (SIZE_OF_FLASH == (256 * 1024)) || (SIZE_OF_FLASH == (128 * 1024)))
#define LPUARTS_AVAILABLE 1
#define LPUARTS_PARALLEL // LPUARTs and UARTs are counted from 0
#elif defined KINETIS_K22 && (SIZE_OF_FLASH == (128 * 1024))
#define DMA_CHANNEL_COUNT 4
#elif defined KINETIS_K22 && (SIZE_OF_FLASH == (128 * 1024))
#define SPI_AVAILABLE 2
Any project that runs on the FRDM-K22F (K22F512 120M) should be able to run on a K22F128 100M by switching between 1, 2, 3 and 5 settings (1, 2 and 3 are usually controlled by a single define once a real target is set up).
Regards
Mark
Mark,
Thank you for the detailed changes. I'll check these out. It might take me awhile as I'm not familiar with the 2.0 SDK or utasker.
Still my biggest problem is I'm using the KSDK 1.3 package right now and have a lot of code developed for it. I'd like to keep using this SDK because I'm comfortable with it and would like to acoid porting it over to the 2.* SDK. You mean more familiare with utasker, but is there away to do these same changes you mentioned, but with the KSDK 1.3. For example modifying the usbd_sdk_bm_lib_MK22F51212 to be compatible and build with the ksdk_platform_lib_K22F12810?
When I tried to build there was errors on defines missing, so if the USB is compatible between the 2 chips then I just need the right defines to add/take away stuff.
-Brendan
Hi Brendan
In fact it should be very easy to move from the K22F120 to K22F100 parts in any environment with framework that anticipates this. I tried once with a KSDK version and with good processor knowledge it is possible but does require quite a lot of work. You need to make a new directory structure for the new part and rename lots of files so they fit in (and don't conflict) - there is a thread where I did this about 18 months ago as exercise at the SDK forum - then modify the things that are different. The differences can be just a few lines of code in some cases but it did need about 500MBytes of new files to be added to be able to actually do it without disrupting everything else. When the next SDK version comes along all work is of course lost again...maintenance is also difficult because lots of different projects need to be modified and maintained for each single change.
If you send me your project (I can give you a free protected GIT account in case you need to keep it secure) I can take a quick look. We offer a free porting service which will allow you to then simulate the project - the uTasker environment is many times more efficient than the one that you have been using and porting a project to be smaller, faster and more modular can usually be achieved in a very short time. Afterwards you will find you can develop much more efficiently and usually greatly shorten project development times.
Depending on the complexity you already have I may be able to send you a complete operating project for your new part so you don't need to go through the usual days and week of tweaking the various incompatible libraries.
Regards
Mark
If you want to give it a quick try, send a contact mail to an address at http://www.utasker.com/support.html - don't get frightened because it is FREE and you may find it will save your company many thousands of $ in the long run.
Mark,
I have a .zip file for the project working with the KSDK 1.3, builds with the ksdk_platform_lib_K22F12810 that I can send to you.
How would you like me to do that?
I also already have the project version controlled, so we don't have to worry about screwing it up too bad.
The project isn't too complex right since I haven't been able to add any api commands, so its just some supporting code for a few sensors and some buttons.
I would assume all the changes would have to be done in the usbd_sdk_bm_lib_MK22F51212. Is that what you did in that post? Can you provide me a link that that?
I also wanted to note at the end that this is for our evaluation board. We weren't able to acquire the 512 chip in enough time to use it with the eval boards, but it will be used in our production units. It's a obnoxious because will have to port the project back and forth because we need to make sure the hardware design (especially USB) is working.
Thanks for the help! I'll let you know on the utasker stuff.
-Brendan
Brendan
In that case just send the zip file you have (ensure it has no *.exe or *.bat files in it because they may cause it to get blocked) to one of the addresses at the link.
I'll then take a look and advice.
You will find that the uTasker project uses a different concept. It has a single project which will run on about 50 different Kinetis references board and allows moving between Kinetis parts with almost no effort. You can switch between your temporary and final processor with easy and so it solves the deficiencies that you are presently encountering with the NXP libraries.
>>Can you provide me a link that that?
I just searched the other forum but couldn't locate my post from then (sorry) and I did it only as an exercise to help someone trying to use an unsupported part so don't have a backup of it. It is presumably there (or maybe in the KDS forum?) somewhere but I have posted thousands of times in the forums and this makes it difficult to locate specific ones....
Regards
Mark
Mark,
Not sure why, but I can not figure out how to attach this .zip file to forum. Can you tell me how to do that or provide an email for me to send it to?
-Brendan
Brendan
You can use an email address at the link.
To attach to the forum post you need to first click on "Use advanced editor" (top right of the thread reply).
then you will have "Attach" in the bottom left corner.
Regards
Mark
Mark,
Awesome thanks! Here you go.
-Brendan
Hi
I couldn't get the project to build as you sent it due to some missing items (or incompatible paths). Not being a fully self-contain project makes it difficult to build it in a different environment.
Therefore I just checked through the code and made a FRDM-K22F board project that does the same. You have a lot of unused source files (prepared for later) which are pretty much all using the two I2C buses. Therefore I just enabled the accelerometer I2C interface so that it shows this in operation (it uses the I2C bus at about 100% load to poll the accelerometer as fast as possible).
I enabled USB-CDC and USB-MSD to allow the internal Flash and SRAM to be shown as hard drives. There is a full command line interface on the UART (OpenSDA VCOM) and also on the USB-CDC interface when connected.
Your main() application has been modified to do the same but without needing to poll (interrupt driver state event) and the K22 sleeps whenever it is not needed to be working to save power. The board is simulated to test all of the operation (and simpler debugging).
I couldn't make out exactly what clock your code uses but I set up to run from the internal 48MHz (using USB clock synchronisation "crystal-less"), 24MHz Flash and Bus - I have a feeing that you may have been operating from the 32kHz clock but this isn't suitable for USB. In any case I enable the RTC from 32kHz oscillator and give it a complete Gregorian calendar system.
I then added a K22F128 target which can be switched to with a define K22F128_100M (instead of FRDM_K22F) (also its corresponding linker script needs to be used due to the memory size differences) and this operate the same on the other chip (with USB). This setup also activates the errata for the 0N75K mask (rather than errata for the 0N50M mask).
You could use the I2C code that you have if you don't mind continuing with blocking operation or you could use the uTasker I2C interface instead for non-blocking operation and better performance, but it would require modifications to the general method.
If you pull the uTasker Open Source project you will find that it now has a define called SPECIAL_TEST in the file application.c where I have planted your code as operating in the main loop (modified so that it is fully interrupt driven and doesn't need to poll).
In config.h there is a new define K22F128_100M so switching between this and FRDM_K22F allows moving between the two board/processors.
You will recognise your code and see the simpler method of configuring the interrupt operation - when any key changes your original polling function is called via a system interrupt event (not in the interrupt).
The buttons and outputs can be simulated if you build the project in Visual Studio so you can click on the inputs to test their interrupt and see the outputs changing in response to your code handling the changes.
It took about 1.5 hours to port your project to the environment on both FRDM-K22F and K22F128-100M targets, add USB and various other features and test on the K22F512-120M. I don't have a K22F128 target but I have tested the operation in the simulator and expect it to run the same on HW (if not it will be a minor detail which can be easily fixed).
If there is anything you don't understand just ask - I certainly recommend building in Visual Studio (in fact it is also possible to debug on the target directly for Visual Studio if Visual GDB is used) so that you can simulate, test and debug the project since it is so much faster than working on the target. If you have difficulties and I find a few minutes I'll maybe post you a video showing your project operating, illustrating the keys' interrupt operation.
Regards
Mark
Mark,
First of all thank you for all your hardwork, I greatly appreciate it!
How do I find this modified project on utasker you are talking about?
-Brendan
Brendan
The open source uTasker project is on GITHUB
Web: https://github.com/uTasker/uTasker-Kinetis
HTTPS: https://github.com/uTasker/uTasker-Kinetis.git
SSH: git@github.com:uTasker/uTasker-Kinetis.git
If you already cloned this previously you just need to pull the latest changes.
If you haven't used GIT before you can follow this video: https://www.youtube.com/watch?v=K8ScSgpgQ6M&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q&index=9 (TortoiseGIT is recommended)
You will find also that your project can now be built with IAR, CodeWarrior, S32, Keil, Rowley Crossworks, CooCox, Green Hills, Atollic, from the GCC make file and in Visual Studio as well as KDS, so it is no longer locked into a single environment.
You need to build the "uTaskerV1.4" project with the option for your project enabled (#define SPECIAL_TEST in application.c) - it simply adds your code to its framework so you can benefit from its many other features without needing to do any extra work.
Regards
Mark
Mark,
I had tortoise installed and was able to clone this project into a directory.
I found uTaskerV1.4 in .../trunk/applications/. I attempted to import the kinetis design studio into my workspace. This worked, but there is only includes. It wouldn't build at all. Am I importing from the wrong area?
-Brendan
Never mind I thought that video was just an intro to GIT not the whole process.
Brendan
I just made a quick video of your code in operation in the simulator, which explains a couple of differences concerning the port and interrupt handling. The video is a bit too big to post here so I put it on Youtube and may delete it again shortly once it has been viewed: https://youtu.be/wXZVfWCt4pc
You may notice that one of the outputs is connected to the RGB LED on the development board and so you will also see the RGB LEDs color changing as the outputs are controlled.
I didn't do any customisation of the board for the simulation but if you are interested in some capabilities this following video shows how important outputs can be visualised specifically
https://www.youtube.com/watch?v=x0oe4kscIDI&index=3&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q
As mentioned earlier it is in fact also possible to use the same environment to debug also the target HW by using VisualGDB, thus allowing complete editing, simulation and code debugging, cross-building and HW debugging in the free Visual Studio Community Edition - I know that engineers expect everything to be free so VisualGDB's price tag of $89 may put off many people from moving to a potentially different level of performance but for those who are open minded and don't only accept an Eclipse environment it has a potential to slash development times and save projects big money in the long term.
Regards
Mark
Hi,
Customer could visit here to create MCU SDK software package for MK22FN128xxx10 product:
The USB demo project located at below default path:
..\SDK_2.2_MK22FN128xxx10\boards\frdmk22f\usb_examples
Thank you for the attention.
Have a great day,
Ma Hui
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Ma Hui,
I was able to build this and found the USB project. But, don't I still need a library to build with this project?
-Brendan
Hi Brendan,
The USB stack was embedded in MCUXpresso SDK software package. Thanks.
Have a great day,
Ma Hui
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hey Ma Hui,
So, unlike using the KSDK 1.3 package I don't have to build any of the platform libraries if I use the MCUXpresso tool. I just build whatever project I'm using?
-Brendan
Hi Brendan,
The MCUXpresso SDK software is different with original KSDK V1.3, customer can use config setting to build a SDK package for one product(or hardware evaluation board).
Have a great day,
Ma Hui
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Mark,
Thanks for your help. With your guides I was able to upgrade the code 2.0 now and have gotten a working USB composite device example. 2.0 seems to be better just because everything is contained in one area.
-Brendan
Hi
Take a look at
http://www.utasker.com/kinetis.html
- http://www.utasker.com/kinetis/FRDM-K22F.html
- http://www.utasker.com/kinetis/TWR-K22F120M.html
- http://www.utasker.com/kinetis/BLAZE_K22.html
- composite devices http://www.utasker.com/kinetis/USB_Device.html
- User's guide http://www.utasker.com/docs/uTasker/USB_User_Guide.PDF
which includes USB stack which is compatible with all K22 parts (just needs SIZE_OF_FLASH and SIZE_OF_RAM set accordingly and adapts itself to the part in question).
Also the USB operation can be simulated in Visual Studio (including interrupt and DMA operation) for learning and operation reviews in critical applications.
Regards
Mark