Unfortunately, MK10DX256VLH7 is the old product which is not supported in the new SDK and the MCUXPresso tools.
If you are using the 70Mhz chip, I suggest you refer to the baremetal project.
You also can check this post:
Wish it helps you!
Thanks for the reply.
What exactly do you mean by the baremetal project? The only software I've found for this chip so far is the stuff that comes with three application notes (AN4419SW, AN4652SW, AN4800SW) for example there are no drivers for many peripherals such as the FTM, dspi, ...
I can write all of this from scratch, but I'd prefer not to if there's an alternative.
I had a quick look through the 100MHz KSDK and there are not a huge number of references to VLQ10, 50 hits over 11 files, many of those being the different chips that come in the same package. They are mostly ifdefs surrounding quite a lot of defines for stuff like the memory map and interrupt vectors etc... How close are these two chips? Will the majority of the KSDK drivers work with my chip if I correctly set up the defines?
The config tools seems to use it's own inbuilt package definitions so I'm pretty certain I'll never be able to use those. It looks like there'sr a .zip of offline data, so I could potentially create a whole bunch of XML files that define my chip and then use those tools, but that seems like more work than it's worth. I can just set up pin muxing and configure the clock registers manually.
Are there any plans to support this (and other currently not supported chips) in the new ksdks? I thought the entire point of the MCUXpresso was to have a common interface for all of NXP's low / mid end micro controllers. I can understand not yet supporting entire families of chips, but not supporting particular packages / speed grades seems like an odd choice. Especially since this is not made clear on the product page. We would likely have not chosen this chip if we had known it wasn't supported in MCUXpresso, which is on me for not properly checking, but still is slightly disappointing.
Hi Andrew Parlane,
The baremetal code is the old code which is based on the register control, not the same format as the ongong SDK. It seems the nxp.com website remove that code package, but my side still have it, it is mainly CW and IAR project:
I have checked the 72Mhz with our SDK department in the previous time, seems no plan to update it.
As you know, the MCUXPresso IDE support also based on the SDK, so the MCUXpresso can't support your chip directly.
If you need the baremetal code, you can create a case from the nxp.com, then I will share it with you, as I can't share it directly in the public community.
This is the process how to create the case:
1. Open below SUPPORT site, click blue "Go to Tickets" in the middle.
2.Then you will be requested to Login, if you have no an account, please first Register with your business email.
3.After login, please "Create New Cases" button in the middle, then you can submit your question.
Sorry for the inconvenience we bring you.
But you still can refer to the baremetal code about the driver.
Hi Kerry, thanks for the reply.
I've created a case requesting that code #00288369.
It would also be nice to formally request that this processor is supported by the new KSDK. Given that the chip is listed as active, I don't think it's too much to ask for that it is formally supported. Please pass this request on to those who can deal with it.
There is support for the K10DX256 70 MHz parts in the open source uTasker project (on Github) which can be used with MCUXpresso, KDS, CW, IAR, Keil, Rowley, CooCox, Greenhills, GCC make and also allows project/chip simulation with VisualStudio.
For professional requirements it is also actively supported in the uTasker Kinetis/i.MX RT developer's project which allows developing code on the K10DX256 70MHz parts that also runs on i.MX RT parts should more performance be required later, without extra development investment.
These parts are equivalent when USB is not used:
[uTasker project developer for Kinetis and i.MX RT]
Hi Mark, thanks for the reply. I'll be certain to use your code as reference. I'm hoping I can repurpose the MK10D10 KSDK, the memory map differs a bit, but I think each peripheral has essentially the same registers.