We have recently purchased KV31F512VLLP12P parts from two different sources and are having the same problem with all of them. When we mount them on our motor controller board, 7 out of 10 did not communicate with KMS. We traced down the problem to a call in the function DSM_init that appears to be the first call to the proprietary code that is locked in the upper 8K section of the processor. Once it calls that function, the processor gets a hard fault. Our conclusion is that the proprietary section either wasn't programmed or somehow we erased it. After trying many different things, we finally took a brand new part and mounted it on one of the Freedom Eval boards and connecting it to KMS. The result was that we still could not communicate with KMS. At this point it appears most of the parts were not programmed when we received them.
Is this a common problem? What can we do to resolve this issue?
KMS is no longer going to be supported by NXP. We are discontinuing distribution of the MCU with KMS pre-programmed and the supporting evaluation boards.
With your same hardware you are able to use the KV31 sensorless FOC reference design software to run your motor. See PMSM motor control at nxp.com/motorcontrol
To address your direct question.
The MCU KV31F512VLLP with KMS comes with the FSEC value set to $EE. This is set to not secure and does not allow mass erase. Some debuggers incorrectly interpret the FSEC value. For instance if the FSEC is not equal to $FE then they think part is secured. This is not the case. $EE is not secure and disallow mass erase.
The P&E debug firmware on the HVP-KV31 and the FRDM-KV31 was correctly designed to interpret the FSEC value.
If you use a P&E debug probe, make sure is has the latest firmware before using it with a pre-programmed part like this. If you are using any other tool make sure that it is properly interpreting the $EE - FSEC value. I have other Kinetis debug probes that still incorrectly think $EE is secure and suggest mass erase.
What is the process you are using to program your code on the KV Flash? It is very likely the process you are using does a mass erase resulting in the KMS code in upper 8 K of memory being erased and getting a hard fault.
My suggesting would be to use a process to do a region or sector erase of the flash you need for your application and program of your code.
If you need assistance in the transition from KMS to our reference design please let us know.
Very disappointed by the news regarding your current PMSM solution and KMS.
To program the parts on our boards we currently are just using one of the Freedom Eval Boards with the SWD pins (SWD_CLK, SWD_DIO, etc) brought out to a connector, running your OpenSDA software through KMS and MCUExpresso. I don't see how this approach could be doing a mass erase. We have parts with the same date codes that work when programmed this way.
I don't believe the sensorless solution will work for us, we need more precision in positioning, and our application is very low speed, < 1 RPM.
If NXP has any other solutions for Sensored control, or if you believe we might still be able to use your sensorless solution, could you provide links for me to look over?
I understand your disappointment and may be able to assist you with your transition. It sounds like you already have hardware designed around the KV31. The hardware need not change.
NXP does have a reference design for high precision motor control with sensor feedback. Currently it is implemented on the i.MXRT10xx platform, but could be ported to KV31 directly.
pavelsustek will need to point you to the most current position control solution.
The mass erase may be happening with the OPENSDA debug firmware. Are you using one of the latest FRDM-KV31 with P&E OPENSDA code version 1.20? if not then the debug firmware did to a mass erase. If not please update to version 1.20. and re-try. You need to put the freedom board in bootloader mode by pressing the reset button while plugging in the usb cable. then drag the .sda file onto the bootloader that enumerates.
Did you connect the Reset pin from the debugger to the target? if not there might be a problem with the debugger taking control of (halting) the target code or lack of code before it attempts an erase and program of the new code.
We are using Eval boards we purchased very recently. The boards have V1.18 of the OpenSDA code on them. I'm not sure if this version has the mass erase issue.
I would appreciate information on the reference design for the iMXRT10xx platform. I could not find anything on the web site.
Yes in fact 1.18 has the mass erase issue. Please update to the 1.20 I provided on the previous post - attached. Or you can go to pemicro.com/opensda and download their update for all of the eval boards.
The reference design for RT is covered in AN12214 - I've attached
There is a zip file with the reference design.
For your learning I reference below tech days training I developed.
Look for i.MX Hands-on -
These additional references are available on www.nxp.com:
I’ve been working with the i.MX RT10xx product lately driving motors. I’m told that the most recent reference designs including the KV and RT product family will be all supported by MCUXpresso in June.