Hello,
I am creating a custom hardware using MKV31F512VLL12P. However, I am not able to communicate with the chip using Kinetis Motor Suite GUI.
I am using FRDM-KL25Z as serial communications device. Here are my connections:
[FRDM-KL25Z, D0, J1:Pin_2] is connected to [MKV31F512VLL12P, PTB16/UART0_RX, Pin_62]
[FRDM-KL25Z, D1, J1:Pin_4] is connected to [MKV31F512VLL12P, PTB17/UART0_TX, Pin_63]
[FRDM-KL25Z, GND] is connected to [MKV31F512VLL12P, GND]
[MKV31F512VLL12P, ~RESET, Pin_52] is connected to 3.3V using a 10k pull-up resistor and to GND using a 100nF.
These are chips I gathered as samples from NXP. Do they have the same behaviour on PTD1, PTD7 and PTE25 pins as they have on the FRDM-KV31F board as RGB LEDs? Should they blink according to status of the program?
What I see on the ~RESET pin is a sawtooth-like waveform at about 1.5 kHz, with a Vpp of 1.7V. Below is a scope shot of this. If I should guess, then this could be the waveform of a blank Kinetis chip fresh from factory..
Then, since this is not a normal operation, with the help of SWD connector on the board, I go to "USBDM Flash Programmer GUI" and do a "Detect Chip" operation. I am being careful here NOT to program or erase. Then, USBDM resets the chip, reads the chip ID successfully, then leaves the ~RESET pin in HIGH level.
Then, I try to connect using Kinetis Motor Suite GUI again, there is data going in at 115200 baud but there is no return. Also, pins PTD1, PTD7 and PTE25 remain LOW.
Signal on ~RESET pin:
Solved! Go to Solution.
What you are seeing on the reset is the MCU trying to execute a blank flash, which fetches from an illegal address and cause an immediate hard fault reset. The reset pin reflects this repeated attempts to run no code.
From the Factory the MCU's default state is not blank at all. See section 3.11 and chapter 13, of the KV31F sub-family Reference Manual.
The KMS library is in the top 8K of flash, protected from erase from mass erase or sector erase with the state of the config bits in the flash from flash address 0x400 to 0x40F. FSEC (0x40C) is set to 0xEE and FPROT0(0x40B) bit 31 is cleared protecting the top 16 K of flash from sector erase.
As specified in the KV31 reference manual there is a one-time use flashloader that is programmed into the flash. The bootloader is present and will run upon power up.
Since you are building your own custom boards you have a few options:
Option 1) You can use the usb to serial converter you have (connected to the flashloader serial port pins defined in the RM, PTE0 is TX and PTE1 is RX) , along with BLHOST commander to do your sector erase and programming of your code into the MCU.
When using the BLHOST and the flashloader I like to use batch files targeted at the com port communicating with the flashloader. if you create a program_kms.bat file with your KMS project binary file referenced then opening a command prompt window and typing > program_kms.bat COM3 would sector erase and program your code into the MCU.
REM verify communications:
blhost -p %1 -- get-property 1
blhost -p %1 -- get-property 12
REM erase region of flash
blhost -p %1 -- flash-erase-region 0x0000 0x70000
REM pogram KMS project file into MCU
blhost -p %1 -- write-memory 0x000 frdmkv31f_snlessvel_KDS.bin
REM readback MCU config space to ensure continued protection from erasure
blhost -p %1 -- read-memory 0x400 16
Option 2) Use the KDS3.2 IDE to download and debug the KMS project to the MCU over the JLINK interface you have.
Option 3) Use the JLINK commander to sector erase and program the KMS project into the MCU.
To sustain the protections set in the flash config the KMS project flash config settings must be updated. The file startup_MKV31F51212.S in the source file list of KMS 1.0.1 project comes with this default:
/* Flash Configuration */
.section .FlashConfig, "a"
.long 0xFFFFFFFF
.long 0xFFFFFFFF
.long 0xFFFFFFFF
.long 0xFFFFFFFE
The config needs to change so that FSEC is 0xEE and FPROT0 (0x040B) bit 31 is clear. As shown below:
/* Flash Configuration */
.section .FlashConfig, "a"
.long 0xFFFFFFFF
.long 0xFFFFFFFF
.long 0x7FFFFFFF
.long 0xFFFFFFEE
This way you continue to protect the KMS library from accidental mass erase.
I hope this helps.
Regards,
Philip
Hello Abdullah and Philip,
I am using the MKV31F512VLL12P and I am facing the same problem.
The first thing that was not clear to me is that does the uC blinks the LED as the FRDM-KV31F from factory?
I tried to upload a generated code from KMS, but at the first time, KDS asked me if I would like to mass erase it, which I did not.
The KMS GUI does not recognize the uC either. What am I missing? Do I have to do something before using KMS?
Sorry to question it again, but I would be grateful to have a more straightforward answer.
Thanks
Fresh from the factory the MKV31F512Vxx12P does have a flashloader programmed into the flash.
The state of the FSEC is set to 0xEE which KDS is interpreting as secure and it is not.
The problem with you set up is that KDS and your debug probe need updating.
It was only last month that P&E updated the eclipse plug in and debug drivers to fix the improper mass erase request when the FSEC was set to disable mass erase but the MCU was unsecure.
At this point KDS will correctly identify the state of the MCU with mass erase disabled and unsecure.
Under the hood of KDS, during debug the programming algorythm has changed and now will do sector or region erase of the flash instead of sumarily doing a mass erase.
Please let me know if you have any futher issues after this.
Regards,
Philip Drake
Hello Pedro,
No, fresh from the factory, MKV31F512VLL12P does not have any program running on it, it is empty. So, it will not do anything at all.
You would need to program it with the code generated from KMS using KDS, or by KMS itself if you have the FRDM-KV31F board.
What you are seeing on the reset is the MCU trying to execute a blank flash, which fetches from an illegal address and cause an immediate hard fault reset. The reset pin reflects this repeated attempts to run no code.
From the Factory the MCU's default state is not blank at all. See section 3.11 and chapter 13, of the KV31F sub-family Reference Manual.
The KMS library is in the top 8K of flash, protected from erase from mass erase or sector erase with the state of the config bits in the flash from flash address 0x400 to 0x40F. FSEC (0x40C) is set to 0xEE and FPROT0(0x40B) bit 31 is cleared protecting the top 16 K of flash from sector erase.
As specified in the KV31 reference manual there is a one-time use flashloader that is programmed into the flash. The bootloader is present and will run upon power up.
Since you are building your own custom boards you have a few options:
Option 1) You can use the usb to serial converter you have (connected to the flashloader serial port pins defined in the RM, PTE0 is TX and PTE1 is RX) , along with BLHOST commander to do your sector erase and programming of your code into the MCU.
When using the BLHOST and the flashloader I like to use batch files targeted at the com port communicating with the flashloader. if you create a program_kms.bat file with your KMS project binary file referenced then opening a command prompt window and typing > program_kms.bat COM3 would sector erase and program your code into the MCU.
REM verify communications:
blhost -p %1 -- get-property 1
blhost -p %1 -- get-property 12
REM erase region of flash
blhost -p %1 -- flash-erase-region 0x0000 0x70000
REM pogram KMS project file into MCU
blhost -p %1 -- write-memory 0x000 frdmkv31f_snlessvel_KDS.bin
REM readback MCU config space to ensure continued protection from erasure
blhost -p %1 -- read-memory 0x400 16
Option 2) Use the KDS3.2 IDE to download and debug the KMS project to the MCU over the JLINK interface you have.
Option 3) Use the JLINK commander to sector erase and program the KMS project into the MCU.
To sustain the protections set in the flash config the KMS project flash config settings must be updated. The file startup_MKV31F51212.S in the source file list of KMS 1.0.1 project comes with this default:
/* Flash Configuration */
.section .FlashConfig, "a"
.long 0xFFFFFFFF
.long 0xFFFFFFFF
.long 0xFFFFFFFF
.long 0xFFFFFFFE
The config needs to change so that FSEC is 0xEE and FPROT0 (0x040B) bit 31 is clear. As shown below:
/* Flash Configuration */
.section .FlashConfig, "a"
.long 0xFFFFFFFF
.long 0xFFFFFFFF
.long 0x7FFFFFFF
.long 0xFFFFFFEE
This way you continue to protect the KMS library from accidental mass erase.
I hope this helps.
Regards,
Philip
Oh, wow, thanks for this great information!
These chips comes blank from factory.
The firmware (application image) for them should be programmed. After that, connection via KMS GUI is possible.
I only have FRDM-KL25Z. In order to program the MCU, JLink_OpenSDA_V2_1.bin that can be found in the "FRDM-KV31F Quick Start Package", is needed to be programmed to the bootloader of FRDM-KL25Z. However, that image does not allow USB-CDC Serial communications. For that, "MSD-DEBUG-FRDM-KL25Z_Pemicro_v118.SDA" or such should be programmed to the bootloader. However, that image does not let programming MKV31F512VLL12P using FRDM-KL25Z. It is only usable for CDC Serial.
It seems like one should buy FRDM-KV31F to properly and easily do development. Oops..