在KE系列MCU中提供了多种寄存器用于实现GPIO的控制：    -PDOR寄存器，用于写入或读取IO的输出状态    -PSOR寄存器，用于置位IO口    -PCOR寄存器，用于清零IO口    -PTOR寄存器，用于翻转IO口    -PDIR寄存器，用于读取IO口的输入状态 当我们想要将PTA0置1时，有多种方法可以选择：    1. 直接操作寄存器，PDOR或PSOR都可以实现：          GPIOA->PDOR |= 0x0001；          GPIOA->PSOR |= 0x0001；          直接操作寄存器的效率更高，但可读性较差。    2. 使用官方的库函数操作       GPIO_PinSet(GPIOA, GPIO_PTA0);       库函数的可读性很好，但显得有些啰嗦，字符较多。 通过KE的BME来实现GPIO的操作能够很好的解决上面的问题，只用将附件中的头文件gpio_bitdef.h包含到工程里，再调用里边的宏定义就可以了。 对PTA0置位和清零可以使用下面的语句： POUTA0 = -1; POUTA0 = 0; 读取PTA0的输入状态则可以使用： tmp = PINA0; 上面的语句是不是看上去简洁了很多呢。 实际上上面GPIO的读写指令，是通过BME的BFI（位域插入）和BFX（位域提取）指令来实现的。 -其中ADDR是存储空间内的地址，我们最终操作的还是GPIO的寄存器，因此在两个指令中分别取GPIOA的PDOR寄存器地址和PDIR寄存器地址。 -bit则表示需要插入或提取位域的起始位置，由于这里是PTA0，PTA0位于寄存器的最低位，因此这里填入了0。 -width则表示需要插入或提取位域的宽度，我们只对单个管脚进行操作，也就是单个位进行操作，宽度自然就是1了。 需要注意的是，BFI（位域插入）指令在插入时，是将对应位插入到目的地址。因此，如果直接为POUTxx赋值为1的话，有可能出现错误。 POUTA0 = 0x01;//正确 POUTA1 = 0x02;//正确 POUTA2 = 0x04;//正确 POUTA1 = 0x01;//错误 为了避免这种情况，我们可以在IO口需要置位时，直接将POUTxx赋值为-1，即0xFFFF FFFF，这样保证了每一位的值都为1。 #define BME_BFI(ADDR,bit,width)        (*(volatile uint32_t *)((((uint32_t)ADDR&0xFFFF))   \                                   | (5 <<28)  \                                   | ((bit)<<23) | ((width-1))<<19)) #define BME_BFX(ADDR,bit,width)        (*(volatile uint32_t *)(((uint32_t)ADDR&0xFFFF)    \                                   | (5 <<28)  \                                   | ((bit)<<23) | ((width-1))<<19))  #define POUTA0 BME_BFI(&GPIOA->PDOR,0,1) #define PINA0 BME_BFX(&GPIOA->PDIR,0,1) ‍‍‍‍‍‍‍‍‍‍

    Curve22519 is a Montgomery elliptic-curve. Such as Apple HomeKit, most of network and IoT software use it in Diffie-Hellman algorithm for key exchanging.     On the Security Kinets MCU chip,if we use just the software algorithm (base on mbedTLS), Curve25519 will spend 180ms for calculation of the shared security.     It is faster than other 256bit elliptic-curve with software algorithm, Because of the shared security calculation will take more than 1200ms with a Weierstrass’s BP256R1curve when use software algorithm.     With LTC ECC HW acceleration, it take only 16ms to calculate the shared security on 256bit elliptic-curve. Whatever you do, the speed of hardware acceleration always faster than the software algorithm.     Now that we should also want to use the LTC to accelerate the Curve22519. The LTC, however, only supported Weierstrass form curve, but Curve22519 is a Montgomery curve…     Although, we can't use LTC in Curve22519 directly, we can use it by mapping it to a Weierstrass form to use it.  As below, we gave parameters of these curves, transform formulas, example code and test result to show how and why to do it. 1. Curve parameter:    Cuvre22519 in Montgomery form:    Y^2 = X^3 + A*X^2 + X    Fp = 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffed    A= 486662    Gx = 9    Gy = 0x20ae19a1b8a086b4e01edd2c7748d14c923d4d7e6d7c61b229e9c5a27eced3d9    Order of G point  =  0x1000000000000000000000000000000014def9dea2f79cd65812631a5cf5d3ed      Cuvre22519 in Weierstrass form :    Y^2 = X^3 + a*X + b    Fp = 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffed    a  =  0x2aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa984914a144L    b  =  0x7b425ed097b425ed097b425ed097b425ed097b425ed097b4260b5e9c7710c864L    Gx = 0x2aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaad245a    Gy = 0x20ae19a1b8a086b4e01edd2c7748d14c923d4d7e6d7c61b229e9c5a27eced3d9    Order of G point  =  0x1000000000000000000000000000000014def9dea2f79cd65812631a5cf5d3ed    2. Calculation formula:   x_w –  x-coordinate value in  Weierstrass form   y_w –  y-coordinate value in  Weierstrass form   x_m - x-coordinate value in  Montgomory form   y_m -  we don’t care y-coordinate value in  Weierstrass mode   a_m – a coefficient of Montgomery equation (   Y^2 = X^3 + a_m * X^2 + X)   a_w – a coefficient of Weierstrass equation (   Y^2 = X^3 + a*X + b )   b_w – a coefficient of Weierstrass equation (   Y^2 = X^3 + a*X + b )     a)  x_w = (x_m + a_m/3)  %  p     b)  y_w ^2 = x_w ^ 3 + a_w*x_w + b_w c)   x_m = (x_w - a_m/3) % p You could reference these document as below: https://en.wikipedia.org/wiki/Curve25519 https://en.wikipedia.org/wiki/Montgomery_curve 3. example code: // public and private at Montgomery end #define M255_d      "0x7178DAC11D42AA5F39B10A62A8584DB0C8864564ADC9DF84EC0B13D9AEC220F8" #define M255_Qx     "0x3BA5048381744348D84E754B9944ABE080B37F7D4158DCE60CD79F66B98AB89E" // public and private at Weierstrass end #define WTS255_d    "0x09CC5CCF43C656C1309EE5A3491D5A8361607CEEB0C9B2B31A575E0FEF2B8835" #define WTS255_Qx   "0x3F4BDE110EE7AF71EF428D1018D188E35BAFB019F34F84E6465C5194B363DC2D" #define WTS255_Qy   "0x7540577CE6F920354E2A9D38CE88847D7447E66FA4D188AC75CB63C17210B718" #define WTS255_Qx_TO_M255_Qx     "0x14A13366643D04C74497E2656E26DE38B105056F48A4DA3B9BB1A6EA08B6B7DC" #define AM_INV3                  "0x2aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaad2451" int ecdh_wts_curve_end( ) {     unsigned int ticks;     int ret = 0;     size_t blen = 0, blen_peer = 0;     ecdh_context ecdh;     ecdh_context ecdh_peer;   // to_wts255     ecdh_context ecdh_peer_m255;     mpi R;     mpi_init(&R);     ecdh_init( &ecdh);     ecdh_init( &ecdh_peer);     ecdh_init( &ecdh_peer_m255);     MPI_CHK(ecp_use_known_dp( &ecdh.grp, ECP_DP_WTS25519 ));     MPI_CHK(ecp_use_known_dp( &ecdh_peer.grp, ECP_DP_WTS25519 ));     MPI_CHK(ecp_use_known_dp( &ecdh_peer_m255.grp, ECP_DP_M255 ));     blen = set_hash_buff(/*TEST_ECP_GRP_ID*/ECP_DP_WTS25519, &secret_buf, ecp_name);     if(blen == 0) {         ret = -1;         goto cleanup;     }     mpi_read_string(&ecdh.d, 16,  WTS255_d);     mpi_read_string(&ecdh.Q.X, 16,  WTS255_Qx);     mpi_read_string(&ecdh.Q.Y, 16,  WTS255_Qy);     mpi_lset(&ecdh.Q.Z, 1);     mpi_read_string(&ecdh_peer_m255.d, 16, M255_d);     mpi_read_string(&ecdh_peer_m255.Q.X, 16, M255_Qx);     mpi_init(&ecdh_peer_m255.Q.Y);     mpi_lset(&ecdh_peer_m255.Q.Z, 1);     // map M255 point to WTS255 point     my_timer_start();     mpi_read_string(&R, 16, AM_INV3);         mpi_add_mpi(&ecdh_peer.Q.X, &ecdh_peer_m255.Q.X, &R);     mpi_mod_mpi(&ecdh_peer.Q.X, &ecdh_peer.Q.X, &ecdh_peer_m255.grp.P);        mpi_lset(&R, 3);     mpi_exp_mod (&ecdh_peer_m255.Q.Y , &ecdh_peer.Q.X, &R, &ecdh_peer_m255.grp.P, NULL);     mpi_mul_mpi(&R, &ecdh_peer.grp.A, &ecdh_peer.Q.X);     mpi_mod_mpi(&R, &R, &ecdh_peer.grp.P);          mpi_add_mpi(&ecdh_peer_m255.Q.Y, &ecdh_peer_m255.Q.Y, &R);     mpi_add_mpi(&ecdh_peer_m255.Q.Y, &ecdh_peer_m255.Q.Y, &ecdh_peer.grp.B);     mpi_mod_mpi(&ecdh_peer_m255.Q.Y, &ecdh_peer_m255.Q.Y, &ecdh_peer.grp.P);     mpi_mod_sqrt(&ecdh_peer.Q.Y, &ecdh_peer_m255.Q.Y, &ecdh_peer_m255.grp.P);     // z = 1     mpi_lset(&ecdh_peer.Q.Z, 1);     MPI_CHK(ecp_copy(&ecdh.Qp,  &ecdh_peer.Q));     MPI_CHK(ecdh_calc_secret_wts2mont( &ecdh, &blen, secret_buf, blen, myrand, NULL));     mpi_read_string(&R, 16, AM_INV3);         mpi_sub_mpi(&ecdh_peer_m255.Q.X, &ecdh.Q.X, &R);     mpi_mod_mpi(&ecdh_peer_m255.Q.X, &ecdh_peer_m255.Q.X, &ecdh_peer_m255.grp.P);     ticks = my_timer_stop();     // print out message     polarssl_printf("Weierstrass curve shared secutiy:\n");     mpi_printf_string( &ecdh.z, 16);     polarssl_printf("%s ecdh peer to peer: %lu ticks, %d ms (%d) \n", ecp_name , ticks, ticks / (CLOCK_SYS_GetPitFreq(0) / 1000),CLOCK_SYS_GetPitFreq(0) );     cleanup:     if( ret !=0 )         polarssl_printf( "%s test Unexpected error, return code = %08X\n", ecp_name, ret );     mpi_free(&R);     ecdh_free( &ecdh);     ecdh_free( &ecdh_peer);     ecdh_free( &ecdh_peer_m255);         return( 0 );    } int ecdh_mont_curve_end( ) {     int verbose = 1;     unsigned int ticks;     int ret = 0;     size_t blen = 0, blen_peer = 0;     ecdh_context ecdh;     ecp_point Q_peer;          // peer public point     ecdh_init( &ecdh);     ecp_point_init( &Q_peer);     MPI_CHK(ecp_use_known_dp( &ecdh.grp, ECP_DP_M255 ));     blen_peer = set_hash_buff(ECP_DP_M255, &secret_buf_peer, ecp_name);     if(blen_peer == 0) {         ret = -1;         goto cleanup;     }     mpi_read_string(&ecdh.d, 16,  M255_d);     mpi_read_string(&ecdh.Q.X, 16,  M255_Qx);     mpi_init(&ecdh.Q.Y);   // don't care Y, only init it     mpi_lset(&ecdh.Q.Z, 1);     mpi_read_string(&Q_peer.X, 16, WTS255_Qx_TO_M255_Qx);     mpi_init(&Q_peer.Y);     mpi_lset(&Q_peer.Z, 1);        MPI_CHK(ecp_copy(&ecdh.Qp,  &Q_peer));     my_timer_start();     MPI_CHK(ecdh_calc_secret( &ecdh, &blen_peer, secret_buf_peer, blen_peer, myrand, NULL));     ticks = my_timer_stop();     polarssl_printf("%s ecdh peer to peer: %lu ticks, %d ms (%d) \n", ecp_name , ticks, ticks / (CLOCK_SYS_GetPitFreq(0) / 1000),CLOCK_SYS_GetPitFreq(0) );     polarssl_printf("Montogemory curve shared secutiy:\n");     mpi_printf_string( &ecdh.z, 16);     polarssl_printf( "passed\n" );     cleanup:     if( ret !=0 && verbose != 0 )         polarssl_printf( "%s test Unexpected error, return code = %08X\n", ecp_name, ret );     ecdh_free( &ecdh);     ecp_point_free( &Q_peer);     if( verbose != 0 )         polarssl_printf( "\n" );         return( 0 );    } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 4. Test result: Test result of curv25519 in  Weierstrass form with LTC:     2. Test result of curve25519 in Montgomery form with software algorithm:      We could see that the shared security both in Weierstrass form with LTC and Montgomery form are “0x1454BDCD6A94D6336AA5A76F3CB40BBE12B65A2CDC9DA6B478948906638896D1”. But the calculation speed with LTC was ten times faster than other one.

  1 Introduction    Previously we used sd card to upgrade the program. We have to insert the sd card into the computer every time, copy the program to the sd card, and then insert it into the sd card slot of mcu to update the program. This method seems to be a bit troublesome, so we implemented a more convenient method. It no longer needs to insert or remove the SD card from PC and MCU. Use the usb function of mcu to recognize mcu as a storage U disk. When we need to update the program, connect the MCU’s usb interface to PC. After the computer recognizes it, copy the program that needs to be burned in. Then the bootloader will recognize the file and then upgrade the application. Bootloader detects changes of the file, not the existence of the file. In other words, if the a000.bin file has already existed in the sd card, the application will not be updated. When this a000.bin is overwritten with another a000.bin, the operation of updating the application will be performed.   2  Bootloader’s implementation The schematic for SD card is shown below. The board uses SDHC module to communicate with SD card.                                                  Figure 1. Figure 1.Schematic for SD card   We use the 2.6.0 version of FRDM-K64F’s SDK. You can download the SDK in our website. The link is “mcuxpresso.nxp.com”.   The schematic for USB is shown below.                                                                                                        Figure 2. Schematic of USB   Bootloader uses SDHC, fatfs, usb, flash, So we should add files to support them. Our code is based on the example “usb_device_msc_sdcard_lite” that belongs to usb example.   In main code, the program will initialize the usb, sd and fatfs. Then the computer will communicate will MCU. Finally, PC will recognize the mcu as a u-disk.                Figure 3.u-disk The method of how to update the program and prepare the application has written in this document. You can refer it. https://community.nxp.com/docs/DOC-344903   Use a variable “wrFlag” to check the modification of the file. When we put file into the u-disk, this variable will be set.                                           Figure 4. Modification of flag When this variable is set, the program will open the “a000.bin”. Then update the application. Finally, go to the application.                      Figure 5. Update the application   3  Run the demo     Download this bootloader     Prepare a user application program. We use the “led blinky” as an example. Use it to generate the binary file. Name it as “a000.bin”. Put it into the u-disk. You will see some log in the uart.       The application will execute automatically

Our debug firmware is generally downloaded from the official website of nxp. nxp.com/opensda. But sometimes we want to modify the source code of bootloader and firmware according to our own requirements. So we introduce the open source project daplink. Arm Mbed DAPLink is an open source software project that can program and debug application software running on the Arm Cortex CPU. DAPLink is usually called interface firmware, and it runs on the auxiliary MCU connected to the SWD or JTAG port of the application MCU. It provides k20 bootloader and interface firmware and k26 bootloader and interface firmware. Many frdm boards use k20 as a debugger, and a few boards use k26 as a debugger. board：FRDM-K64 OS：WIN10   steps： 1.Install git, python2.7.11 or above, add these two software to the computer system environment variables (required), it is best to add the scripts folder under python to the environment variables, and install keil.  DAPlink currently only supports IDE keil. 2.Use python to install pip, you can search for tutorials online 3.Install virtualenv, use powershell (hold down shift and click the right mouse button), Input ‘pip install virtualenv’ 4.After that, the commands are all completed under powershell. Get the source code. Input ‘git clone https://github.com/mbedmicro/DAPLink’ Note: You must use git to download the code, or you will fail at compiling the code. It Will generate a DAPLink folder in your current directory 5.Enter the directory. Input ‘cd DAPLink’， The docs/DEVELOPERS-GUIDE.md under this folder is more detailed how to use this DAPLink 6.Create a virtual environment，Input ’virtualenv venv’ 7.Input ‘venv/Scripts/activate.bat’ to active the virtual environment 8.Install necessary tools，’pip install -r requirements.txt’ 9.Generate keil project, input ‘progen generate -t uvision’ It will generate projectfiles/uvision, enter the folder and you will find various bootloader and firmware. The name with ‘bl’ is the bootloader, and the name with ‘if’ is the interface firmware, which is to be dragged into the mcu. Open the first project about k20. After compilation, a bin file will be generated. The bin file with crc is what we want to burn or drag. For the name ‘if’ is the same. The git command will be called during compilation. If you do not add this command to the environment variable, the compilation will fail. This is the bootloader source code Bin file This is interface firmware. The generated bin file with ‘0x’ is firmware address. Generally, the default firmware address of the DAPLink bootloader is 0x8000. As you can see from the above figure, this macro defines DAPLINK_ROM_IF_START, so the file we want to drag is the file with the name ‘0x8000’. If the firmware start address is modified in the bootloader, the interface firmware should also be modified accordingly Burn the bootloader into k20, then drag the interface firmware into k20 to see this result.  

Please note that the document shown above is an approximation of the original document.

Hi: Kinetis's ADC have no multi channels sequence sampling function, compared with LPC's ADC. But we could use DMA for such case, attached are two demos: 1.multi_channels_edma_ADC_DMA_SW_TRIG Description: use SW trigger DMA transfer for 6 ADC channels, DMA ch0 is for ADC channels transfer, DMA ch1 is for ADC sample result transfer in DMA ch1 ISR, report ADC sample are done; 2.multi_channels_edma_ADC_DMA_LPIT_HW_TRIG Description: use LPIT timely trigger DMA transfer for 6 ADC channels, DMA ch0 is for ADC channels transfer, DMA ch1 is for ADC sample result transfer in DMA ch1 ISR, report ADC sample are done; but LPIT could trigger continuously without SW engage.

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-332687

1. Introduction MCUboot is a common used bootloader for most of Kinetis and i.mx RT devices. It can support download application via UART/USB/CAN/I2C/SPI. It enables quick and easy programming of Kinetis MCUs and i.mx RT MPU through the entire product life cycle, including application development, final product manufacturing, and beyond. K64 is a very popular device in Kinetis family. It has a M4 core, 512k and above flash, 120M main frequency and plenty of interface, such as I2C/SPI/UART/CAN/USB/ENET. But it is a bit awkward that the MCUboot demo of K64 is not include CAN. Does K64’s CAN can’t support bootloader application? No, of course not. Here we are going to port CAN function to K64 bootloader. There are two kind of CAN peripheral in Kinetis family, FlexCAN and MSCAN. FlexCAN is more complex than MSCAN. K64 has a FlexCAN. To speed up our work, we can port FlexCAN driver and related code from TWR-KV46 bootloader. Hardware: two TWR-SER board two sets of TWR-ELEV TWR-K65F150M TWR-K64F120M   Software: MCUXpresso 11.0 MCUBoot 2.0.0 package SDK_2.6.0_TWR-K64F120M 2. Software porting Step 1, copy below files to twrk64f120m_tower_bootloader project. \drivers\fsl_flexcan.c \drivers\fsl_flexcan.h        \source\bootloader\src\flexcan_peripheral_interface.c   Step 2, modify the project to enable the FlexCAN.       In bootloader_config.h, change BL_CONFIG_CAN definition to 1.        In peripherals_MK64F12.c, add #if BL_CONFIG_CAN     // CAN0     {.typeMask = kPeripheralType_CAN,      .instance = 0,      .pinmuxConfig = can_pinmux_config,      .controlInterface = &g_flexcanControlInterface,      .byteInterface = &g_flexcanByteInterface,      .packetInterface = &g_framingPacketInterface }, #endif    // BL_CONFIG_CAN       Pin mux setting. In peripherals_pinmux.h, add #define BL_ENABLE_PINMUX_CAN0 (BL_CONFIG_CAN) //! CAN pinmux configurations #define CAN0_RX_PORT_BASE PORTB #define CAN0_RX_GPIO_PIN_NUM 18             // PIN 13 in the PTA group #define CAN0_RX_FUNC_ALT_MODE kPORT_MuxAlt2 // ALT mode for CAN0 RX functionality for pin 13 #define CAN0_TX_PORT_BASE PORTB #define CAN0_TX_GPIO_PIN_NUM 19             // PIN 12 in the PTA group #define CAN0_TX_FUNC_ALT_MODE kPORT_MuxAlt2 // ALT mode for CAN0 TX functionality for pin 12       Set clock. FlexCAN clock source can be OSCERCLK or bus clock. Here we use bus clock run at 48Mhz. In flexcan_peripheral.c, add these code. const flexcan_timing_config_t bit_rate_table48m[] = {     { 23, 3, 4, 4, 4 }, /* 125 kHz */     { 11, 3, 4, 4, 4 }, /* 250 kHz */     { 5, 3, 4, 4, 4 },  /* 500 kHz */     { 3, 3, 4, 4, 4 },  /* 750 kHz */     { 2, 3, 4, 4, 4 }   /* 1   MHz */ }; change line 621 FLEXCAN_SetTimingConfig((CAN_Type *)baseAddr, &bit_rate_table48m[s_flexcanInfo.baudrate]); Step 3, compile the project.   3. Function test Software preparation To connect bootloader via CAN bus, NXP has TWR-K65 as bridge. But its source code is not in K64 SDK. It is in MCUBoot2.0.0 package. User can download the package from https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools/mcuboot-mcu-bootloader-for-nxp-microcontrollers:MCUBOOT The bridge project is called buspal which can be found in NXP_Kinetis_Bootloader_2_0_0\apps\bus_pal\MK65F18. BusPal is an embedded software tool that is available as a companion to blhost. The tool acts as a bus translator with an established connection with blhost over UART and with the target device over I2C, SPI, or CAN, and assists blhost in carrying out commands and responses from the USB target device. The BusPal is available for selected platforms. The source code for BusPal is provided with the Kinetis bootloader release, it support FRDM-KL25, TWR-KV46F150M and TWR-K65F180M and can be customized to run on other platforms. More detail of buspal is in Kinetis blhost User's Guide appendix C.   Hardware connection TWR-SER has TJA1050 as transceiver. We can connect J7 on both boards. When construct the Tower system, user should take care the power. The power tree is very flexible. Improper setting may cause TJA1050 can’t work.   The Buspal project on TWR-K65F180M use UART1 to connect with computer. The port is on TWR-SER. To make the connection simple, we can share the openSDA UART port. The openSDA UART use UART2, we can jump UART1 signal to J33 and J34 on K65 tower board.     Testing: Open a command window, type >blhost -p com4,57600 –buspal can,0,321,123 – get-property 10 This command can check if the whole system work properly. Then, you can download the code to K64 now. Please type >blhost -p com4,57600 –buspal can,0,321,123 – flash-image xxxxxx.s19 erase

You can put the code directory in the SDK_2.6.0_FRDM-K64F\boards\frdmk64f to use. 1、Introduction As is known to all, we use debugger to download the program or debug the device. FRDMK64 have the opsenSDA interface on the board, so wo do not need other’s debugger. But if we want to design a board without debugger but can download the program, we can use the bootloader. The bootloader is a small program designed to update the program with the interface such as UART,I2C,SPI and so on. This document will describe a simple bootloader based on the FRDMK64F.The board uses SD card to update the application. User can put the binary file into the card. When the card insert to the board ,the board will update the application automatically. The bootloader code and application code are all provided so that you can test it on your own board.   2、Bootloader’s implementation   The schematic for SD card is shown below. The board uses SDHC module to communicate with SD card.                                                  Figure 1.Schematic for SD card   We use the 2.6.0 version of FRDM-K64F’s SDK.You can download the SDK in our website. The link is “mcuxpresso.nxp.com”. The bootloader uses SDHC and fafts file system. So we should add files to support it.                   Figure 2.The support file   In main code, the program will wait until the card has inserted. Then it will find the file named “a000.bin” in sd card to update the application. If the file do not exist, the board will directly execute the application. If there is no application, the program will end. The following code shows how the program wait for inserting sd card. It will also check if the address has the application’s address.                      Figure 3.The code -- wait for inserting card   The following code shows how the program opens the binary file. If sd card doesn’t have the file, the program will go to the application. Figure 4.Open the binary file   If the program opens the file normally, the update will begin. It will erase 200k’s space from 0xa000. You can adjust it according to your project. Now I will explain update’s method in detail. Our data is written to the buffer called “rBUff”. The buffer size is 4K. Before write data to it, it is cleared.  Please note that when we erase or program the flash, we should disable all interrupts and when the operations finish we should enable the interrupts.  The file size will decide which way to write the data to flash.  1、If the size < 4k ,we just read the file’s data to buffer and judge if its size aligned with 8 byte. If not , we increase the size of “readSize” to read more data in our data buffer called “rBuffer”. The more data we read is just 0.    2、If the size > 4K, we use “remainSize” to record how much data is left. We read 4k each time until its size is smaller than 4k and then repeat step 1. When finish the operation at a  time, we should clear the buffer and increase the sector numer to prepare the next transmission. Figure 5.Write flash operation code   The way to clear the space is shown in the figure. It will initialize the flash and erase the given size from the given address.  “SectorNum” is used to show which sector to erase. Figure 6.Erase operation code   The following figure shows how to write the data to flash.              Figure 7.Program operation code    Before we go to the application, we should modify the configuration we did in the bootloader.     Close the systick, clear its value.     Set the VTOR to default value.     Our bootloader runs in PEE mode. So we should change it to FEI mode.     Disable the all pins. You should disable the global interrupt when run these codes. And don’t forget to enable the global interrupt. Figure 8.Deinitalization code   Then we can go to the application. Figure 9.Go to Application   3、Memory relocation The FRDMK64 has the 1M flash, from 0x00000000 to 0x00100000.As shown in figure 10,we use the 0xa000 as the application’s start address.            Figure 10.The memory map   Now, I will show you how to modify the link file for user application in different IDE. In IAR                                    Figure 11.IAR’s ICF In MDK Figure 12.MDK’s SCF   In MCUXpresso Figure 13.MCUXpresso’s flash configuration 4、Run the demo 1) Download the bootloader first. 2) Prepare a user application program. We use the “led blinky” as an example. 3) Modify the Link file. 4) Generate the binary file with your IDE, please name it as “a000.bin”. 5) Put it into the sd card like figure 5. Figure 14.SD card’s content        6) Insert the card. And power on. Wait for a moment, the application will execute automatically. 5、Reference 1) Kinetis MCU的bootloader解决方案 2) KEA128_can_bootloader

[中文翻译版] 见附件 原文链接： https://community.nxp.com/docs/DOC-335320

I have included the files needed to mass erase the flash of the MCU and re-program another binary.   The procedure is shown in the folder " FRDM-KW31_FAT_added_2019" Summarizing you... 1) update the debugger with bootloader mode (press reset and plug in usb cable) drag and drop .sda file on MSD bootloader. 2) unplug and re-plug USB. program the flashloader_loader_mkv31f512.bin by dragging and dropping the binary on to the virtual mass storage device FRDM-KV31 which appear when you plug the USB cable from the FRDM-KV31 to the PC.  3) Open a CMD prompt window and navigate to the folder the files were unzipped to. 4) Determine the COM port by using the device manager 5) from the CMD prompt run the batch file      Erase_KMS_program_bubble.bat COMX

This years annual hacker security conference known as DEFCON used a couple of NXP devices for this years electronic badge. This document is to explain how to program the device and add extra components. The badge was developed by Grand Idea Studio, with engineering help from NXP, and this presentation has details about the development of the badge. I'm the NXP systems engineer that was helping people get started with reprogramming their badge at Defcon, and wanted to create something that gives all the details on how to do that yourself.  Full schematics and firmware source code can be found at: http://www.grandideastudio.com/defcon-27-badge/   The badge has these two NXP devices:  KL27  - MKL27Z64VDA4 - 48Mhz ARM Cortex M0+ microcontroller w/ 64KB flash (Datasheet and Reference Manual) NXH2261UK- Near Field Magnetic Induction (NFMI) chip for the wireless communication. Has a range on the badge of about 6 inches (15cm), but the technology can work a bit further. It's often found in high end headphones because BLE waves are disrupted by your head but these waves aren't. Also less power consumption. Using the serial port: There's a serial interface which prints out helpful information and there's some "secrets" available if you have a completely leveled up badge. It'll also be really helpful if you're writing new code to hack your badge for printf debugging. Note that you cannot program the board by default over the serial port. This particular chip doesn't support that, though some of our other chips do. It of course would be possible to write a serial bootloader for it, but that's definitely not beginner level. You'll need two pieces of hardware: 1) Header Pins 3) Serial-to-USB converter Header Pin: You can solder on a header to the PCB footprint. Because of the quartz, the leads would need to be flat on the PCB. A Harwin M20-8770442 will fit the footprint and is what was provided at the soldering village and what you see in the photos below. You could also try creating your own header.  Serial to USB Converter: Since almost no computer today comes with a serial port, a serial to USB converter dongle is needed. It'll have four pins: GND, Power, TX, and RX. The DEFCON badge runs at 1.8V, but the chip itself is rated up to 3.6V, so a 3.3V dongle can be used *as long as you do not connect the power pin on the serial header*. You only need to connect GND, RX, and TX. In a production design you would not want an IO voltage above VCC, but for hacking purposes it'll work, and I've used it all week without an issue on multiple boards.  There's a lot of options. Here's a 1.8V one if you want to be extra cautious or a 3.3V one that already comes with connectors for $8. Anything that transmits at 1.8V or 3.3V will work so you may already have one, but again, just don't connect the power pin.    Software: You'll need to install a serial terminal program like TeraTerm or Putty.  1) Plug the 3.3V or 1.8V USB converter dongle into your computer and it should enumerate as a COM port.  2) Connect the GND line on the dongle to GND on the header 3) Connect the TX pin on the dongle to the RX pin on the header 4) Connect the RX pin on the dongle to the TX pin on the header (it is not RX to RX, I spent 2 whole days tearing my hair out over that during my robotics project in college) 5) DO NOT CONNECT THE POWER PIN  5) Should look like the following when finished 6) In your serial terminal program, connect to the COM port your dongle enumerated as 7) Find the serial port settings menu (in TeraTerm it's in Setup->Serial Port from the menu bar) , and set the baud rate to 115200. The other settings should not need to be changed (8 data bits, no parity, 1 stop bit).  😎 In the terminal, press enter. You should get a > prompt 9) In the terminal, press the '?' key on your keyboard, and hit enter, you'll see the menu.         10) Note that the key you press won't show up in the terminal, but just press Enter and then the command will be run 11) Hit Ctrl+x to exit interactive mode and turn back on the radio.  12) While not in interactive mode, the terminal will display the transmit packet of any badge you bring close to it.  Reprogramming Your Badge: Hardware:  There's two pieces of hardware needed: 1) Programmer/debugger 2) Programming cable Program Debugger: Most any ARM Cortex M debug programmer can be used, as the KL27 chip has a ARM M0+ core. I'd recommend the LPC-Link2 as it's only $20 and can be bought directly from NXP or from most distributors (like Mouser or DIgikey). Search for "OM13054". But you could also use a J-Link, PEMicro, or others if you already have an ARM programmer. Cable: The DEFCON badge has the footprint for a Tag Connect TC2050-IDC-NL-050-ALL. Because this cable is meant for manufacture programming and not day-to-day debugging, if you plan on stepping through code, you'll also want to pop off the the quartz front and get some retainer clips to keep the programmer connected to the board. If you just simply want to reprogram the board, you can just snip off the 3 long guide clips, and press the cable against the PCB while holding your hand steady for the ~5 seconds it takes to flash it each time.  Alternatively if you already have a JTAG/SWD cable and have soldering skills, you can use some fine gauge wire and hack up your own converter to your board like /u/videlen did with some true hacker soldering. However as /u/int23h pointed out, because it's using Single Wire Debug (SWD) you only need to really solder 2 of the pins, SWDIO and SWDCLK. However nRESET is also recommended as it'll let you take control of the device if it's in sleep mode (which it is most of the time). Power (which is needed so the programmer knows what voltage to send the signals at) and GND you can get from the serial header. Software There's three pieces of software you'll need:  1) Compiler 2) MCUXpresso SDK for the KL27  3) Badge source code Compiler: Recommended Option: Latest version of MCUXpresso IDE - available for Windows, Mac, and Linux Second Option: Download older version of MCUXpresso IDE for Windows from the DEFCON media server  Third Option: If you use the latest SDK, you can easily use ARM-GCC, IAR, or Keil tool chains as well.  MCUXpresso SDK: Recommend Option: Download latest SDK version for KL27 - includes setup for MCUXpresso IDE, ARM-GCC, IAR, and Keil compilers Other option: Download the older 2.4.2 SDK version on the DEFCON server which only has MCUXpresso IDE compiler support.  Badge Source: Recommended Option: Download zip off Joe Grand Website: http://www.grandideastudio.com/wp-content/uploads/dc27_bdg_source.zip  Other option: Download from DEFCON media server. However the .project and .cproject files do not show up by default, so you must make sure to explicitly download them as well and put them in the main firmware folder (at the same level as the .mex file). These are the exact same files as in the zip.  wget -r -np -R "index.html*" https://media.defcon.org/DEF%20CON%2027/DEF%20CON%2027%20badge/Firmware/ wget  https://media.defcon.org/DEF%20CON%2027/DEF%20CON%2027%20badge/Firmware/.cproject wget  https://media.defcon.org/DEF%20CON%2027/DEF%20CON%2027%20badge/Firmware/.project  Getting Started with MCUXpresso IDE:      1) Open up MCUXpresso IDE. When it asks for a workspace directory to use, select (or make) a new empty directory that is in a different location than where you          downloaded the firmware source.       2) Drag and drop the SDK .zip file from your file system into the MCUXpresso IDE "Installed SDKs" window. This is how the compiler learns about the KL27 device and the flash algorithms.  3) Drag and drop the badge firmware folder from a file explorer window into the MCUXpresso IDE "Project Explorer" window 4) In the Quickstart panel hit Build 5) In the Console tab, you should see the message that it compiled successfully 7) In the Quickstart panel hit Debug.  If you're not using a LPC Link2 for programming, you'll need to hold Shift when clicking this the first time so it'll rescan for your debugger.  If using the latest MCUXpresso IDE, you'll see a dialog box that the launch configuration needs to be updated. Click on "Yes".    7) A dialog box will come up confirming your debug probe. 😎 Connect the programming cable to the board and press to make a good connection. Make sure the alignment pins match up with the alignment holes on the PCB, and that pin 1 (the red stripe) matches the photo below. You may hear the badge beep, as it's being reset. 9) Then hit OK in the dialog box to start programming. Make sure to keep the probe held there until the programming is finished - about 5 seconds. 10) You should see it program successfully and hear the board beep as it reboots.  Programming Troubleshooting/Tips: If you're not using a LPC Link2, hold down the Shift key when you hit the Debug button, and it'll re-search for new probes. Also make sure your debug settings and probe is using SWD mode and not JTAG mode.  If you have the programming cable not lined up with the pads, you'll see this error. Re-align your probe and try again. Also you must have power from the battery as the MCU needs to be turned on while programming. You can hit the GUI flash programmer at the top for a quicker download experience since it won't load the debug view. Useful if just flashing the device without wanting to step through code.  Finally, some of the game state variables are stored in the non-volitale internal flash, and may not automatically get erased when reprogramming the firmware as the programmer doesn't realize that area of flash memory is being used and thus to save time, doesn't bother to erase it. You can force a complete erase of the flash to wipe all the game variables by setting the mass erase option. Double click on the dc27_badge LinkServer Debug.launch file which contains the debug settings, and go to GUI Flash Tool->Program and set Program (mass erase first).  Getting Started with ARM-GCC: To make this easier, you'll need to download the latest SDK from the NXP website first.  Follow the instructions in Section 6 of the MCUXpresso SDK User Guide for how to setup the environment and test it out on Hello World. You can then use that project for copying the badge source code into. I'm sure someone can put together a Makefile for the badge specifically. See this series of blog posts on how to use the SDK (compiling/debugging) with arm-gcc in Linux. My badge isn't working: First thing to try is power cycling the badge by gently prying the battery out (with a butter knife or something) and putting it back in. A couple of things might happen: If nothing at all happens, you battery might be dead. Try replacing the battery.  If nothing at all happens still, the battery holder might be loose. Use a multimeter ot measure the voltage between GND and VCC on the serial header, it should read 1.8V. If it does not, check the battery holder. If you hear beeps, all 6 LEDs light up, and then 4 LEDs (2 on each side) flash in sync a few times, it means there was an issue communicating with the NFMI device. This could be due to a loose solder joint on one of the chips or the I2C pull up resistors (SCL and SDA on the pinout image). You could also do a reflow if you have the equipment, but it may not be fixable. Also could see if see any I2C communication on those SCL/SDA pins. If you hear a normal startup beep, the lights flash, and then it goes back to the startup beep, and so on, forever, something is causing the MCU to keep resetting. Could be a short or ESD damage. Check soldering. Connecting your board to a serial terminal and see how far it gets in the boot process to help narrow down the cause.  Sometimes the flags don't get saved properly. A power cycle usually works, and could also try reflashing the badge.  If your badge isn't responding to other badges with the NFMI, it could be one of two things: Your copper antenna is loose/broken/missing. This happened a lot. Solder it back on. If missing, it's a Sunlord MTNF6040FS3R7JTFY01 but it's not available online anywhere at the moment. Datasheet is here. See this post for more details on possible alternatives. If you were previously in interactive mode, you have to explicitly exit it with Ctrl+X to receive packets again.  Further hacking: For basic hacking of the code, try changing your game flags to trick it to giving you a fully unlocked badge. From there, you could try to make your own chameleon badge like others have done (https://github.com/japd06/defcon27_badge and https://github.com/nkaminski/DC27-badge-CFW and https://github.com/NickEngmann/Jackp0t among others if you want ideas). Or make your own songs with the piezo. Or some ASCII art on the terminal. For more advanced hacking on the badge, PTE22 and PTE23, the TX and RX pins on the serial header, could be programmed to be ADC input pins instead. Or timer inputs or outputs for PWM or input capture.  And with some good soldering, you could even add an additional I2C device by soldering to the resistor points. t.   Finally if you want a more flexible platform for exploring embedded development, you can pick up a FRDM-KL27Z dev kit for $20 which has the same chip as the badge. You can buy it direct or all major distributors online. The programmer and serial interface are built into the board so you only need to use a USB cable to do all the programming. The KL27 SDK also includes dozens of example programs that show how to use all the features of the chip and there's some getting started videos (mostly what I covered already in this post though). While it does not have a NFMI chip on it, it does have USB support, as well as an Arduino hardware footprint on it so it can be easily expanded with extra boards. You can find the example programs by going to "Import SDK examples" from the Quickstart panel window.  If you have any more questions about the badge, post a response! 

The following document contains a list of documents , questions and discussions that are relevant in the community based on the amount of views they are receiving each month. If you are having a problem, doubt or getting started in Kinetis processors or MCUXpresso, you should check the following links to see if your doubt have been already solved in the following documents and discussions. MCUXpresso MCUXpresso Supported Devices Table FAQ: MCUXpresso Software and Tools  Getting Started with MCUXpresso and FRDM-K64F  Generating a downloadable MCUXpresso SDK v.2 package  Quick Start Guide – Using MCUXpresso SDK with PINs&amp;CLOCKs Config Tools  Moving to MCUXpresso IDE from Kinetis Design Studio Kinetis Microcontrollers Guides and examples Using RTC module on FRDM-KL25Z  Baremetal code examples using FRDM-K64F Using IAR EWARM to program flash configuration field Understanding FlexIO  Kinetis K80 FAQ How To: Secure e-mail client (SMTP + SSL) with KSDK1.3 + WolfSSL for FRDM-K64F  Kinetis Bootloader to Update Multiple Devices in a Network - for Cortex-M0+  PIT- ADC- DMA Example for FRDM-KL25z, FRDM-K64F, TWR-K60D100 and TWR-K70  USB tethering host (RNDIS protocol) implementation for Kinetis - How to use your cellphone to provide internet connectivity for your Freedom Board using KSDK Write / read the internal flash Tracking down Hard Faults  How to create chain of pbuf's to be sent? Send data using UDP.  Kinetis Boot Loader for SREC UART, SD Card and USB-MSD loading  USB VID/PID numbers for small manufacturers and such like  Open SDA and FreeMaster OpenSDAv2  Freedom OpenSDA Firmware Issues Reported on Windows 10 Let´s start with FreeMASTER!  The Kinetis Design Studio IDE (KDS IDE) is no longer being actively developed and is not recommended for new designs. The MCUXpresso IDE has now replaced the Kinetis Design Studio IDE as the recommended software development toolchain for NXP’s Kinetis, LPC and i.MX RT Cortex-M based devices. However, this documents continue to receive considerable amount of views in 2019 which means it could be useful to some people. Kinetis Design Studio New Kinetis Design Studio v3.2.0 available Using Kinetis Design Studio v3.x with Kinetis SDK v2.0  GDB Debugging with Kinetis Design Studio  KDS Debug Configurations (OpenOCD, P&amp;E, Segger) How to use printf() to print string to Console and UART in KDS2.0  Kinetis Design Studio - enabling C++ in KSDK projects  Using MK20DX256xxx7 with KDS and KSDK  Kinetis SDK Kinetis SDK FAQ  Introducing Kinetis SDK v2  How to: install KSDK 2.0  Writing my first KSDK1.2 Application in KDS3.0 - Hello World and Toggle LED with GPIO Interrupt 

The SysTick is a part of the Cortex-M0+ core and so is not chip specific - for details of the Cortex core you generally need to use ARM documents. For SysTick: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0179b/ar01s02s08.html By summary, the SysTick is configured through four registers: 1. SysTick Control and Status(CSR): basic control of SysTick e.g. enable, clock source, interrupt or poll COUNTFLAG: count-down flag, if down to 0, then this bit will be set to 1, otherwise, it will be 0. CLKSOURCE:  when using internal core clock, it will be 1. If using external clock, it will be 0. TICKINT: interrupt enabled when setting to 1. ENABLE: counter enabled when setting to 1. 2. SysTick Reload Value(RVR): value to load Current Value register when 0 is reached. 3. SysTick Current Value (CVR): the current value of the count down. 4.SysTick Calibration Value(CALIB): contain the number of ticks to generate a 10ms interval and other information, depending on the implementation. TENMS: tick value for 10 ms. To configure the SysTick you need to load the SysTick Reload Value register with the interval required between SysTick events. The timer interrupt or COUNTFLAG bit is activated on the transition from 1 to 0, therefore it activates every n+1 clock ticks. If a period of 100 is required 99 should be written to the SysTick Reload Value register. See attached code on how to generate microsecond delay.

Many customers reported that their ADC function works on FRDM-KL27Z board but meet issue on their own board. We need to pay attention to the difference between the ADC reference voltages of different packages (on board MKL27Z64VLH4 is 64LQFP package). This tip introduce the ADC Reference Options on KL17/KL27 32/36pin package Part number involved: 32-pins 36-pins MKL17Z32VFM4 MKL17Z32VDA4 MKL17Z64VFM4 MKL17Z64VDA4 MKL27Z32VFM4 MKL27Z32VDA4 MKL27Z64VFM4 MKL27Z64VDA4 PTE30/VREF_OUT- connected as the primary reference option on 36-pin and below packages VDDA/VSSA - connected as the VALT reference option   ADCx_SC2[REFSEL] selects the voltage reference source used for conversions.   About the primary reference option: When on-chip 1.2V VREF is enabled, PTE30 pin must be used as VREF_OUT and has to be configured as an analog input, such as ADC0_SE23 (PORTE_PCR30[MUX] = 000). Notice: this pin needs to connect a capacitor to ground.   PTE30 can also be used as an external reference voltage input as long as PTE30 is configured as analog input and VREF module is disabled. It means you can connect external reference voltage to PTE30 pin and use it as ADC reference voltage. (For example 3.3V) KL17P64M48SF2RM     Kinetis KL17: 48MHz Cortex-M0+ 32-64KB Flash (32-64pin) (REV 4.1) KL27P64M48SF2RM     Kinetis KL27: 48MHz Cortex-M0+ 32-64KB Flash (32-64pin) (REV 4.1)

As most of people familiar with FRDM-K64F which is a bit old but it is still a hot device in the market. This document focused on the ADC measurement to verify the deviation. In general, the sample code were modified /come with MCUXpresso SDK, which is an ADC polling example. ADC reading was done by two ways: 1) Polling the status register of ADC conversion complete flag until ADC conversion is done. 2) CPU core is in sleep right after ADC conversion is started by software trigger. Interrupt is generated when ADC conversion is done and CPU core wakes up by this interrupt. The value of ADC reading is measured 5000 times. And, it is averaged, also calculate max/min value. Finally, the standard deviation is calculated based on the 5000 measured value. PRINTF is a terminal console and print out by semi-hosting. Interrupt method or polling method can been selected by the define of INTERRUPT or POLLING. #define INTERRUPT 0   //ADC conversion wait for “INTERRUPT” should be defined to 1 #define POLLING 1 　　//ADC conversion wait for “POLLING” should be defined to 1

The DOC introduces the nano-edge placement  feature for KV4x family, it gives the application for the nano-edge placement feature, in other words, it's target is to increase the PWM signal resolution. It gives the example code and PWM waveform for the nano-edge placement feature.

For motor control and swich mode power supply application, it is required that the ADC sampling is synchronized with PWM signal. In general, most Kinetis sub-family provides FTM, PDB and ADC, it provides a mechanism for ADC converter is synchronizedc with PWM signal. But the KEA family does not have PDB module, instead, the KEA family provides a simple mechanism which enables PWM signal the FTM module generate can synchronize the ADC converter. The DOC introduces the mechanism, give the register configuration description, code and scope screenshot on how the PWM signal synchronizes the ADC.

Test environment: FRDM-K64F Rev.D IAR ARM Workbench IDE V8.30.1 MCUXpresso SDK for FRDM-K64F v2.4.2(2018-08-02) Test project is [ftm_output_compare] located with default path: ..\FRDM-K64F\boards\frdmk64f\driver_examples\ftm\output_compare Test reason to verify the CnV register is updated on the next FTM counter change. Three test signals: FTM0_CH0 pin as output compare pin will generate square signal with 1.33KHz . FTM0_CH1 pin generate 24KHz Edge-Aligned PWM signal(High-true pulses (clear Output on match)) with 50% duty cycle as FTM counter monitor. When FTM counter change, the FTM0_CH1 will toggle to output high voltage. Test using a delay() function to emulate modify FTM0_CH0 output compare mode and CnV value periodically. There is a GPIO pin will toggle after each delay() function to detect/verify the CnV value actual load point. FlexTimer module setting: The FTM0 refer clock is 60MHz For the FTM0_CH1 pin generate 24KHz PWM signal, the FTM0 MOD value is fixed to 0x9C3 (60MHz/24KHz = 2500).   Below is the overall signals: Test Process Record: During FTM0 module initialization, set the FTM0_CH0 pin output compare value to 0xA00 (more than MOD register value (0x9C3)) with below code: Set the CnV value more than MOD register is to avoid the output compare be set during at start. After that,  enable FTM0 counter and toggle GPIO pin to set a mark: After delay, toggle GPIO pin and update CnV register to 0x270 (the match point is half of the PWM high voltage). The actual signal is : After the first CH0 output compare set match, before set CH0 pin clear on match. It need to keep the CH0 pin with same output compare mode and set CnV back to 0xA00 (more than MOD) again with below code: Then we set CH0 with clear on match mode and update CnV value to 0x752 (middle of CH1 PWM low voltage): The actual signal is: With the similar code, before next CH0 set on match, it need to keep the CH0 pin with same match compare mode setting and CnV change back to 0xA00 (more than MOD). The actual signal is below: Note: During the output compare signal compare mode set/clear change phase, it need to keep previous output compare mode setting, please don't using kFTM_NoOutputSignal setting at code. Otherwise, the output compare signal will exist decay: Test Result: From FTM0 register value, the FTM0_SYNCONF[SWRSTCNT] bit is clear, which means select Legacy PWM synchronization method. The legacy PWM synchronization method will update Output Compare mode CnV register value at the next FTM counter change. The actual signal also verify it. Below is FTM0 all registers value: For the more detailed info, please check the original thread at here. Please check attachment about test code.

Test Environment: FRDM-KL43Z Rev. A MCUXpresso IDE v10.2.0 MCUXpresso SDK for FRDM-KL43Z V2.4.1(2018-06-18) Create new project in MCUXpresso IDE select [New project...], there will pop the SDK Wizard panel, then select [frdmkl43z]: Then, click [Next] will enter into [Configure the project] panel, we can set the [Project name] and select [flexio_i2s] in [driver]: Click [Finish], the new project was created. In general, the project is based on [hello_world] project with board default console available. In [Project Explorer], we could find the <fsl_flexio_i2s.c> & <fsl_flexio_i2s.h> & <fsl_flexio.c> & <fsl_flexio.h> files in drivers folder: Edit the code The application note AN5397 detailed introduce how FlexIO emulate I2S bus communication. The MCUXpresso SDK <flexio_i2s> driver using the AN5397 showed second solution to use two timers and two shifters. Please check here to get more detailed info. The I2S signal was below, we need to use four FlexIO pins to provide: BCLK, Fss, TxData & RxData. In <pin_mux.c> file, it need to config pin function, we use PTD7 pin provide I2S BCLK clock; PTD6 pin as I2S Frame_sync pin; PTD5 pin as Tx data pin; PTD6 pin as Rx data pin; In <frdmkl43z_flexio_i2s_interrupt_tx.c>,  config flexio_i2s and config the audio frame format: Please check attached source code for the detailed project info. Test result From the actual measured I2S signal, it shows the 8 bytes was sent out: