This document describes the different source clocks and the main modules that manage which clock source is used to derive the system clocks that exists on the Kinetis devices. It’s important to know the different clock sources available on our devices, modifying the default clock configuration may have different purposes since increasing the processor performance, achieving specific baud rates for serial communications, power saving, or simply getting a known base reference for a clock timer. The hardware used for this document is the following: Kinetis:  FRDM-K64F Keep in mind that the described hardware and management clock modules in this document are a general overview of the different platforms and the devices listed above are used as a reference example, some terms and hardware modules functionality may vary between devices of the same platform. For more detailed information about the device hardware modules, please refer to your specific device Reference Manual. Kinetis platforms The Kinetis devices have a main module called Multipurpose Clock Generator (MCG) this module controls which clock source is used to derive the system clocks. A high-level description diagram is shown below: Figure 1. Multipurpose Clock Generator External clock sources can provide a frequency signal as the System oscillator module or the RTC oscillator module, also the MCG module has internal clock generators that the System integration module (SIM) manages, the SIM module provides module-specific clock gating to allow granular shutoff of modules. For more detailed information about the SIM module, refer to “Chapter 12. System Integration Module(SIM)” from the K64 Sub-Family Reference Manual.  The following clock diagram shows all the multiplexers, dividers, and clock gates that can be controlled by the MCG, however, we will focus on the external and internal clock sources and the MCG outputs. Figure 2. Oscillators,  MCG and SIM modules At ‘MCGOUTCLK’ line, the primary clocks for the system are generated, the circuitry provides fixed clock dividers for the Core clock, Bus clock, FlexBus clock, and the Flash Clock. This allows for trade-offs between performance and power dissipation. It’s important to know that the MCG has 9 states of operation shown in the following figure.    Figure 3. MCG operation states In the previous image, the arrows indicate the permitted MCG state transitions, for example, if the current MCG state is BLPI(Bypassed Low Power Internal) and the desired state is BLPE(Bypassed Low Power External) the shortest and allowed path to follow is first switch to FBI(FLL Bypassed Internal) then to FBE(FLL Bypassed External), and finally to the BLPE MCG state. These switching mode restrictions exist due to certain MCG configuration bits that must be changed to properly move from one mode to another. For example, in the K64 family, the MCG state after a power-on reset is FEI(FLL Engaged Internal) mode, the MCGOUTCLK is derived from the FLL clock that is controlled by the 32kHz Internal Reference Clock (IRC), the following table shows the output frequency values for this specific MCG state. Source Frequency MCGOUTCLK 20.97MHZ Core/System clocks 20.97MHz Bus clock 10.48MHz FlexBus clock 6.99MHz Flash clock 4.19MHz Table 1. K64 default MCG configuration after reset: FEI (FLL Engaged Internal) The following image shows the blocks used for the FEI state using Clocks Tool from MCUXpresso IDE. Figure 4. View of FEI state from Clock Tools For more detailed information, refer to “Chapter 25. Multipurpose Clock Generator (MCG)” from the K64 Sub-Family Reference Manual.  External Clock Sources     System oscillator The System Oscillator module is a crystal oscillator. The module, in conjunction with an external crystal or resonator, generates a reference clock for the MCU.  Supports 32 kHz crystals (Low Range mode) and supports 3–8 MHz, 8–32 MHz crystals and resonators (High Range mode) For more detailed information, refer to Chapter 26. Oscillator(OSC) at K64 Sub-Family Reference Manual.   RTC oscillator The RTC oscillator module, in conjunction with an external crystal, generates a reference clock source of 1Hz and 32.768KHz, supports 32 kHz crystals with very low power. For more detailed information, refer to Chapter 27. RTC Oscillator(OSC32K) at K64 Sub-Family Reference Manual.   Internal Clock Sources    IRC oscillators Internal clock driven by the Fast Internal Reference (FIR) @4MHz or the Slow Internal Reference (SIR) @32kHz.  IRC internal oscillator Internal 48 MHz oscillator that can be used as a reference to the MCG and also may clock some on-chip modules. PLL Phase-locked loop circuit that in conjunction with an external clock source can achieve higher and stable frequencies.   FLL Frequency-locked loop circuit that in conjunction with an internal/external clock source provides module-specific clock and achieves higher frequencies. Modifying MCG state from FEI to FBI state If the current system clock does not fit with our timing requirements we can modify it by changing the state of the MCG module, in this case, if the user requires a lower system clock frequency @32.7KHz(Slow IRC) or @4MHz(Fast IRC) instead @21MHz(FLL Engaged Internal ‘FEI’ default state) and a low power option of the MCG module, the FLL Bypass Internal (FBI) state is an option to reach these requirements. 1.1 Configure MCG mode The FBI state allows us to use the Fast IRC together with its frequency divider achieving frequencies between 31.25KHz to 4MHz, for this example the final core clock is @2MHz. Follow the next steps to change to the FBI state and select a 2MHz clock using the Clock-Tools tool from MCUXpresso IDE.        At the MCUXpresso QuickStart Panel select MCUXpresso Config Tools >> Open Clocks Figure 5. Open Config Tools        At the left top of the screen select the MCG mode to “FBI(FLL Bypassed Internal)” Figure 6. Selection of MCG Mode        Select the frequency divider block(FCRDIV) right-click on it and select “Edit settings of: FCRDIV” Figure 7. FCRDIV block        Modify the divider value from 1 to 2. Figure 8. FCRDIV divider value        Finally, the next image shows how the MCG state and the new yellow paths get modified. The Core and system clocks are @2MHz. Figure 9. FBI MCG state @2MHz 1.2 Export clock configuration to the project After you complete the clock configuration, the Clock Tool will update the source code in clock_config.c and clock_config.h, including all the clock functional groups that we created with the tool. In the previous example, we configured the MCG state to FBI mode, this is translated to the following instructions in source code: “CLOCK_SetInternalRefClkConfig();” and “CLOCK_SetFbiMode();”  Figure 10. Source code view of FBI MCG configuration Another way to change the MCG state is by directly modifying the internal MCG registers. The blocks shown in the following image need to be modified to switch from the default FEI state to the FBI state. Figure 11. Blocks in FEI state to modify at MCG registers Note. MCG registers can only be written in supervisor mode. The ARM core runs in privileged(supervisor mode) out of reset, it is controlled by [nPRIV] bit in CONTROL core register. For more detailed information visit the Cortex-M4 ARM Documentation Reference Manual.        Internal Reference Source Multiplexor (IREFS), selects the reference source clock for the FLL.  1 is written to C1[IREFS]. The slow internal reference is selected.        PLL Select  Multiplexor(PLLS) Controls whether the PLL or FLL output is selected. 0 is written to C6[PLLS] The FLL output is selected as the MCG source, the PLL is disabled.        Clock Source Select Multiplexor(CLKS), selects the clock source for the MCGOUTCLK  line. 01 is written to C1[CLKS].  The internal reference clock is selected at the CLKS multiplexor.        Fast Clock Internal Reference Divider(FCRDIV), selects the Fast Internal Reference Clock divider, the resulting frequency can be in the range of 31.25KHz to 4MHz. 001 is written to SC[FCRDIV]. The dividing factor is 2 since the desired frequency is @2MHz and the source clock is @4MHz.        Internal Reference Clock Select (IRCS). Selects between the fast or slow internal reference clock source.  x is written to C2[IRCS]. Write 0 for Slow IRC or 1 for Fast IRC.        Finally, to enable the low power when neither the PLL nor FLL are used, a register in C2[LP] is modified. x is written to C2[LP]. Enable, or Disable the PLL & FLL in all the bypass modes.     This is translated to the following instructions in source code in “CLOCK_SetInternalRefClkConfig();” and “CLOCK_SetFbiMode();” functions:  Figure 12. Source code view of Internal MCG Registers Note. C1, C2, C6, and SC registers are part of the internal MCG control registers.  References K64 Sub-Family Reference Manual Also visit LPC's System Clocks   

分享自China-FAE team同事，在此谢过！ 有客户需要bootloader功能，于是从网上下到最新版本的AN2295，发现里面添加了很多的内容，包括支持了很多新的器件，比如KM系列，但是真正把它在板子上跑起来，却花了2天时间，为了减少大家工作量，不在重蹈覆辙，我在这里share给大家，目前该代码在FRDM_KL25以及TWR-K60D100M上跑起来了。遇到的问题主要有如下几点： 问题1： 在工程中使用除法命令： a =a /100; 会报错： Error[Li005]: no definition for "__aeabi_uidiv" [referenced from D:\Customer\XinRuiYang\an2295sw_Kl25\src\Kinetis\IAR_6_4\Kinetis L Debug\Obj\bootloader.o] 原因是： 这里Lib选择的是None，说明没有使用任何库，所以不能使用除法。 打开库后，可能会占用比较大的空间，所以不推荐使用。 问题2： FRDM_KL25使用默认代码频率，波特率有问题，发送data = 0但是实际发送值为0x80，通过更改主频为48M，然后分频解决。附件有参考代码。TWR-K60100DM没有此问题。 问题3： FRDM_KL25板子，如果不使能BOOTLOADER_AUTO_TRIMMING这个宏，即不调用SlaveFrequencyCalibration();函数时， 代码上电不能直接运行，而使能该函数后，会一直进行校准频率，上位机无法通讯，查找代码发现： 上版代码为         #if BOOTLOADER_AUTO_TRIMMING == 1                       if(UART_GetChar() != BOOT_CMD_ACK)              {                SlaveFrequencyCalibration();              }                                        #endif 本版代码为：         #if BOOTLOADER_AUTO_TRIMMING == 1                         SlaveFrequencyCalibration();                     #endif 修改为上版代码，可以正常运行并跑起来。 但是不使能BOOTLOADER_AUTO_TRIMMING这个宏，代码依旧跑不起来，现象就是仿真时没有问题，可以正常跑起来，但是如果是上电直接运行，就不能正常通讯： 这个问题出在了USB插拔瞬间，KL25会收到一个数据，该数据并不是上位机下发的FC码，如果不使能BOOTLOADER_AUTO_TRIMMING这个宏，代码会误认为自己进入 等待上位机下发数据的状态机，导致通讯错误。在SlaveFrequencyCalibration(); 函数中，有软件复位功能，会让插拔稳定后KL25不在接收到异常数据，以此保证状态机的正确。 问题4： 仿真时全速跑起来时，指针经常回到__main,说明波特率有问题，代码进入SlaveFrequencyCalibration中，复位了。 AN2295引导MQX Keil工程 AN2295的文档已经说明如何修改CW IAR的工程以便让Bootlaoder引导，但是没有Keil工程的说明，这个就只能自己动手啦。 首先肯定会想到修改scf文件： #define USERFLASH_BASE_ADDR    0x00060000 #define INTFLASH_BASE_ADDR     0x00000000 #define INTFLASH_SIZE          (USERFLASH_BASE_ADDR - INTFLASH_BASE_ADDR) #define MY_ALIGN(address, alignment) ((address + (alignment-1)) AND ~(alignment-1)) LOAD_REGION_INTFLASH INTFLASH_BASE_ADDR INTFLASH_SIZE {     VECTORS INTFLASH_BASE_ADDR     {         vectors.o (.vectors_rom,+FIRST)         vectors.o (.cfmconfig)     }     CODE +0     {         * (InRoot$$Sections)      ; All library sections for example, __main.o,                                   ; __scatter*.o, __dc*.o, and * Region$$Table         * (KERNEL)         * (TEXT)         * (+RO)     }     RAM_VECTORS 0x1FFF0000 ; For ram vector table. Used when  MQX_ROM_VECTORS is set to zero.     {         vectors.o (.vectors_ram)     }     NOUSER +0     {         * (.nouser)     }     ROUSER MY_ALIGN(ImageLimit(NOUSER), 32)     {         * (.rouser)     }     RWUSER MY_ALIGN(ImageLimit(ROUSER), 32)     {         * (.rwuser)     }     DATA MY_ALIGN(ImageLimit(RWUSER), 32)     {         * (+RW)         * (+ZI)     }     USB_BDT MY_ALIGN(ImageLimit(DATA), 512)     {         * (.usb_bdt)     }     KERNEL_DATA_START MY_ALIGN(ImageLimit(USB_BDT), 0x10)     {         * (KERNEL_DATA_START)     ; start of kernel data     }     KERNEL_DATA_END 0x2000FFF0      ; RAM_END     {         * (KERNEL_DATA_END)     ; end of kernel data     }     ; mem_init writes a storeblock_struct at the end of kernel data,     ; max size 32 bytes, so use 0x100 offset     BOOT_STACK_ADDR 0x2000FEF0     {         * (BOOT_STACK)     } } 都是按偏移算的，应该只改INTFLASH_BASE_ADDR     0x00004000就O了，找了个最简单的工程：mqx\examples\hello，编译生成S19文件，通过bootloader下载进片子， 按reset后看屏幕，始终木有出现hello world，没办法，只能上debug了。 打开AN2295工程，加载调试环境，然后在JumpToUserApplication函数上下断点，中断后，单步执行到在__asm("mov pc, r1"); 函数，继续在汇编窗口点单步执行，之后就完全跟crack有点类似，一直点，直到芯片复位，说明之前点那一下是key point，然后对照map文件，于是找到了复位点： init_hardware->_bsp_initialize_hardware->_bsp_watchdog_disable();执行后会复位 不管啦，直接把它屏蔽掉，反正之前就已经关闭看门狗了。 重新编译，继续上。 还是没看到期待已久的hello world，肿么办？ 重复上面的方法，发现又一个key point: _sched_start_internal 查看代码发现，这是一个系统call，应该是从vector 11调用的，查看下寄存器： SCB_VTOR 肿么变成0了，bootloader中已经改成0x4000了，什么时候变成0了....... 代码太多了，不知道从哪儿看起，内存断点是个好东西哈，IAR中没找见在哪儿下，算了，换Keil吧。 用Keil打开AN2295工程，加载调试，然后在0xE000ED08（SCB_VTOR ）下写断点，直接run，等待中断吧： _time_set_timer_vector函数修改了SCB_VTOR， 大概路径是_bsp_enable_card->BSP_INTERRUPT_VECTOR_TABLE->BSP_TIMER_INTERRUPT_VECTOR 哈哈，找代码看看： __VECTOR_TABLE_ROM_START 是这个宏搞的鬼。 仔细对比代码，发现__VECTOR_TABLE_ROM_START 这个宏是通过条件编译区分开的，IAR是通过icf文件定义的 而Keil是通过#define 来实现的。好了，修改对应的值为0x4000，重新编译，下载，搞定，可以看到hello world喽。 总结一下，使用AN2295引导MQX Keil工程需要做以下3点修改： 1.scf文件INTFLASH_BASE_ADDR     0x00000000改为0x00004000 2.屏蔽_bsp_watchdog_disable()该函数 3.修改__VECTOR_TABLE_ROM_START为0x00004000.

Hello, I've created a application of USB FLASH Drive acessing the 1MB internal FLASH of K64 using the Freescale's bareboard USB Stack 5.0 software + FRDM-K64F to be used by anyone as reference. It seems to be stable, I already wrote some files on that and checked the integrity of the volume. It can be very useful for datalogger application where the equipment can store data on the MCU FLASH using a internal filesystem, and read it through PC as it was a regular USB stick. It also very much cheaper than using a external SD Card, as it only needs the MCU + a external crystal and a USB connector.The only limitation so far is that it cannot exceed the number of the erase/write cycles of the device (of course!). Please see the file attached with the USB Stack and the example on the folder "{Installation Path}\Freescale_BM_USB_Stack_v5.0\Src\example\device\msd\bm\iar\dev_msd_disk_frdmk64f". The project was wrote using IAR. Also I have attached the srec file if you don't want to build the project by yourself. Any issues, doubts or suggestions, please let me know. Denis

NXP 的BLE芯片目前包括QN902x 和 Kinetis KW3x两大系列，NXP BLE Solution 主页为：Bluetooth Smart|Bluetooth Low Energy|BLE|恩智浦 1）QN902x系列包括QN9020和QN9021，他们主要区别是封装不同，QN9020为QFN48（6x6mm），QN9021为QFN32（5x5mm）。QN902x的主要技术参数如下： 》Cortex- M0内核 》支持BLE4.1 》96Kb ROM，128Kb SPI Flash ，64Kb RAM 。代码在RAM中执行 》最高工作频率32Mhz 》输出功率：-20~4dBm；接收灵敏度：-95dBm 》功耗：接收电流：9.25mA，发送电流：8.8mA ，sleep mode：3uA 该芯片的datasheet：http://cache.nxp.com/documents/data_sheet/QN902X.pdf?fpsp=1&WT_TYPE=Data%20Sheets&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf… 官方的评估板为QN9020DK，链接为：高度可扩展的QN9020应用开发平台|恩智浦 另外一第三方公司也有一套开发板，可用来评估QN902x芯片，其连接地址为：FireBLE - Firefly wiki 2）KW3x，包括KW30和KW31两个系列，KW30 具体信息可以参考：KW30Z|Kinetis Bluetooth Low Energy MCU|恩智浦 KW31具体信息可以参考：KW31ZlKinetis BLE无线MCU|恩智浦 随便说下，NXP还有一个KW4x系列，该芯片可以同时支持Zigbee和BLE，它包括KW40和KW41，主页分别为：KW40Z|Kinetis BLE & 802.15.4无线MCU|恩智浦 和KW41ZlKinetis BLE & 802.15.4无线MCU|恩智浦

Here you will find both the code and project files for the ADC project. This project configures the ADC to perform single conversions, by default this is performed using a 16 bit configuration. The code uses ADC0, channel 12, once the conversion is finished it is displayed at the serial terminal. Code: #include "mbed.h" AnalogIn AnIn(A0); DigitalOut led(LED1); Serial pc(USBTX,USBRX); float x; int main() {     pc.printf(" ADC demo code\r\n");     while (1)     {     x=AnIn.read();     pc.printf("ADC0_Ch12=(%d)\r\n", x);     wait(.2);     } }

1 Abstract Stepper motor can be controlled by the electrical pulse signal with the open loop system, it use the electrical pulse signal realize the angular movement or linear movement.  The speed and position of the stepper motor is determined by the pulse frequent and the pulse number. Stepper motor can be used in the low speed area application, with higher work efficiency and low noise. KE02 is the 5V kinetis E series MCU, it is based on ARM Cortex M0+ core, KE series are designed to maintain high robustness for complex electrical noise environment and high reliability application. For these advantages, KE02 is fit the Stepper motor control application. This document is mainly about how use the KE02 realize the Stepper motor speed, step and direction control. It can use the UART in the PC to control the Stepper motor speed. The following picture is the control diagram.                                                                              Fig.1 2. Motor control parameter calculation      Just as Fig.1 shows, KE02 should control the EN, DIR, PWM signal to the motor driver, then realize the stepper motor control. EN is the motor driver enable signal, 0 is enable, 1 is disable; DIR is the stepper motor direction control, 0, clockwise, 1 anticlockwise; PWM is the pulse signal to control the step and speed for the stepper motor.       Stepper motor is 1.8’, it means a round have 360’/1.8’= 200 steps. But because the Motor driver have the divider, it is 32, so one stepper motor round should have 200*32 = 6400 steps.       KE02 system, it use the external 10Mhz crystal, and configure both core and bus frequent to 20Mhz,  it use FTM0 module as the motor pulse generate module, bus clock with 32 prescale used as the FTM0 clock source, choose up counter. If need to change the motor speed and control step, just control the FTM PWM frequent and PWM counter. For Stepper motor, one FTM period means one motor step. From the reference manual of KE02, we get that, the FTM period in up counting mode is: (MOD-CNTIN+1)*period of the FTM counter clock, if want to change the frequent of motor, just calculate the MOD of FTM is ok, then count the number of the FTM cycle, now assume CNTIN =0, then: Tftm= (32/20Mhz)*(MOD+1) From the Stepper Motor and it’s driver, we get that one step time is : Tmstep= 60/(V*6400) V is the speed of Motor, the unit is round/minute. Because Tftm=Tmstep, then we know: MOD= (60/(V*6400))*(20Mhz/32)-1                     (F1) In this document, we calculate the speed of 150 round/minute, 110 round/minute, 80 round/minute, 50 round/minute and 0.1 round/minute, according to (F1), we can get the MOD for each speed as the following: 150 round/minute   MOD=38 110 round/minute   MOD=52 80 round/minute     MOD=72 50 round/minute     MOD=116 0.1 round/minute    MOD=58592 If each speed need to do 10 Stepper motor round, then just control the speed counter number to: 10*6400=64000. 3. MCU pin assignment PTF0 : DIR PTF1 : EN PTA0 : PWM PTC6 : UART1_RX PTC7 : UART1_TX 4. code writing (1)FTM initial code void STEEPMOTOR_PWM_Init(uint16 MODdata) {                    SIM_SCGC |= SIM_SCGC_FTM0_MASK;                 FTM0_SC = 0;                 FTM0_C0SC = 0 ;                 FTM0_C0SC = FTM_CnSC_MSB_MASK |FTM_CnSC_ELSA_MASK ;                 FTM0_C0V = 0;                 FTM0_C0V = MODdata>>1;                 FTM0_MOD=MODdata;                 FTM0_SC |=FTM_SC_CLKS(1) | FTM_SC_PS(5) | FTM_SC_TOIE_MASK                 enable_irq(17); //enable interrupt } MODdata can choose the different Stepper motor speed, eg, 150 round/minute, MODdata is 38. (2) interrupt service function void FTM0_IRQHandler(void) {                                 FTM0_SC  &= ~FTM_SC_TOF_MASK;//clear the TOF flag. roundcount++;                 if(roundcount >= 64000) {FTM0_C0SC = 0x00; FTM0_SC &= ~(FTM_SC_TOIE_MASK);} } It can used for the step counter, and when reach the 10round, then stop the motor( stop the FTM output). (3)Speed choose with UART input void Motor_Speed_GPIO_CTRL_30round(void) {                 char motormode=0;                 uint32 COMPDATA=0;                                 printf("\n 1 for 150 round/minute\n\r");                 printf("\n 2 for 110 round/minute\n\r");                 printf("\n 3 for 80 round/minute\n\r");                    printf("\n 4 for 50 round/minute\n\r");                    printf("\n 5 for 0.1 round/minute\n\r");                 motormode = UART_getchar(PC_TERM_PORT);                                     switch(motormode)                                 {                                    case '1':                                                       STEEPMOTOR_PWM_Init(38);//150 round/minute                                                         break;                                   case '2':                                                       STEEPMOTOR_PWM_Init(52);//110 round/minute                                                         break;                                   case '3':                                                                       STEEPMOTOR_PWM_Init(72);//80 round/minute                                                          break;                                   case '4':                                                                       STEEPMOTOR_PWM_Init(116);//50 round/minute                                                         break;                                   case '5':                                                                       STEEPMOTOR_PWM_Init(58592);//0.1 round/minute                                                         break;                                                                                default: break;                                 }                                 while( roundcount < 64000 ) {} //10 round                                 Disable_PWM;                                 printf("\n %c 10round PWM is finished ", motormode);                                 roundcount=0; } 5 DEMO About the test code, please find it from the attachment.

The board used: FRDM-KE02 SWD: The ARM Serial Wire Debug interface uses a single bidirectional data connection(SWDIO) and a separate clock (SWDCLK) to transfer data synchronously. An operation on the wire consists of two or three phases: Packet request       The external host debugger issues a request to the DP. The DP is the target of the request. Acknowledge response   The target sends an acknowledge response to the host. Data transfer phase First enter into SWD mode: Send at least 50 SWCLKTCK cycles with SWDIOTMS HIGH and 0xE79E. This ensures that the current interface is in its reset state and enable the SWD mode. uint8_t SWJ_JTAG2SWD(void) {     uint32_t i;     SWDIO_SET();     for(i = 0; i < 56; i++)     {         SW_CLOCK_CYCLE();     }     SWJ_SendData(0xE79E);//SWJ_SendData(0xB76D);以后遇到再加     for(i = 0; i < 56; i++)     {         SW_CLOCK_CYCLE();     }     SWDIO_CLR();     for(i = 0; i < 16; i++)     {         SW_CLOCK_CYCLE();     }     return 0; } Then write DP/AP register. A successful write operation is as below: DP Register: Address     Read              Write 0x00        IDCODE           ABORT 0x04        CTRL/STAT      CTRL/STAT 0x08        RESEND           SELECT 0x0C        RDBUFF           N/A Address     Read              Write 0x00         CSW               CSW 0x04         TAR               TAR 0x08         N/A                N/A 0x0C         DRW              DRW 0xFC         IDR                N/A Read IDCODE： uint8_t SWJ_ReadDP(uint8_t adr, uint32_t *val) {     uint32_t tmp_in;     uint8_t ack;     uint8_t err;     tmp_in = SWD_REG_DP | SWD_REG_R | SWD_REG_ADR(adr);     ack = SWD_Transfer(tmp_in, val);     (ack == DAP_TRANSFER_OK) ? (err = 0) : (err = 1);     return err; } uint8_t SWJ_ReadAP(uint32_t adr, uint32_t *val) {     uint8_t tmp_in, ack, err;     uint32_t apsel = adr & APSEL;     uint32_t bank_sel = adr & APBANKSEL;     if(SWJ_WriteDP(DP_SELECT, apsel | bank_sel))     {         return 1;     } tmp_in = SWD_REG_AP | SWD_REG_R | SWD_REG_ADR(adr);     /* first dummy read */     ack = SWD_Transfer(tmp_in, val);     ack = SWD_Transfer(tmp_in, val);     (ack == DAP_TRANSFER_OK) ? (err = 0) : (err = 1);     return err; }

作者 Sam Wang & River Liang 在RISC架构的MCU中，通常是加载-存储（Load and Store）的操作机制，而这种方式不能提供传统8bit架构MCU的直接位操作内存和地址空间。为此飞思卡尔在M0+系列MCU上集成了BME（Bit Manipulation Engine）位操作引擎功能，例如KE和KL系列里都带有BME，它从硬件上提供了对外设地址空间用读-修改-写的操作方式来实现位操作。         使用BME能够降低总线的占用率和CPU执行时间，这些效果都能够降低系统的功耗。另外使用相比于用C语言实现相同功能的代码，使用BME能够更节省代码空间。这些可以参照         BME功能支持访问从0x4000_0000开始的，大小为512K的地址空间，并把它映射成从0x4400_0000到0x5fff_ffff的内存空间。         好了，长话短说。下面转入正题，我们应该如何使用BME来进行位操作，并达到节省代码空间、提高效率的效果。 一、写操作方式，对定义内容用写的方式来实现与、或、异或、位域插入功能 1：BME的&操作可以一次对IO的几个bit清0     //     0x21<<26 | addr (A0~A19) //GPIOA_PDOR   地址为   400F_F000 #define GPIOA_AND *((volatile unsigned char *) (0x44000000+0xFF000)) 例: GPIOA_AND=0xaa; #define GPIOA_AND_I *((volatile unsigned int *) (0x44000000+0xFF000)) 例: GPIOA_AND_I=0x55aa; 实际上命令是将400f_f000的内容与目标数进行&运算。修改volatile unsigned char, volatile unsigned int, volatile unsigned long来实现BME的所谓8,16,32位操作.下面命令相同。 2：BME的|操作可以一次对IO的几个bit置1     //       0x22<<26 | addr (A0~A19) #define GPIOA_OR *((volatile unsigned char *) (0x48000000+0xFF000)) 例: GPIOA_OR=0xaa; #define GPIOA_OR_I *((volatile unsigned int *) (0x48000000+0xFF000)) 例: GPIOA_OR_I=0x55aa; 实际上命令是将400f_f000的内容与目标数进行|运算。 3： BME的^操作          //     0x23<<26 | addr (A0~A19) #define GPIOA_XOR *((volatile unsigned char *) (0x4C000000+0xFF000)) 例：GPIOA_XOR=0xaa; #define GPIOA_XOR_I *((volatile unsigned int *) (0x4C000000+0xFF000)) 例: GPIOA_XOR_=0x55aa; 上面3个例子讲解了一般的与、或、异或等常用操作，下面来点复杂一点的。                                                                                           4： BME的位域插入操作BFI（Bit Field Insert）//   (5<<28) | (bit<<23) | (width<<19) | addr (A0~A18) #define BME_BFI_ADDR (ADDR, BIT, WIDTH)   (*(volatile uint32_t *) (((uint32_t) ADDR) | (1<<28) | (BIT<<23) | (WIDTH<<19))) 在这里bit是插入的位置，表示被操作目标的最低位开始被操作，Width这里是插入的数据长度 例：BME_BFI_ADDR(&ADC0_CFG1, 0x05, 0x01) = 0x40; 结果是将寄存器ADC0_CFG1从bit5开始，用0x40的bit5来替换ADC0_CFG1的bit5，0x40的bit6来替换ADC0_CFG1的bit6，调用该命令后，寄存器ADC0_CFG1_ADIV = 2 相当于执行了mask = ((1 << (w+1)) - 1) << b;                          //等一系列位操作。                             (ADC0_CFG1 & ~mask) | (0x40 & mask); 使用BFI功能需要注意的是，操作地址是A0到A18，而GPIO寄存器的A0到A19是从FF000开始，因此会有1bit 的地址冲突。为此，在使用BFI操作GPIO的寄存器时，使用的是内存映射出来的地址空间，此时GPIO的起始地址将为F000，如果还使用原来的地址，命令将会无效。之前提到的AND、OR、XOR操作，对于GPIO地址空间在FF000还是F000都适用 #define BME_BFI_GPIOA (BIT, WIDTH)        (*(volatile uint32_t *) ((uint32_t) (5<<28) | (BIT<<23) | (WIDTH<<19) | 0xF000)) 例：BME_BFI_GPIOA(0,3) = 0x0a; 结果是GPIO_PDOR从bit0开始，一共4位被1010替换了。 二、读操作方式 5, BME的读操作使某位置1, Load-and-Set 1 Bit// #define PTA1_SET   (void) (*((volatile unsigned char *) (0x4C000000+ (1<<21) + 0xF000))) #define PTA1_SET_I   (void) (*((volatile unsigned int *) (0x4C000000+ (1<<21) + 0xF000))) 例: PTA1_SET;   //效果是GPIOA1高电平         LAS1      第1位    GPIOA_PDOR地址的A0-A15 6, BME的读操作使某位清0, Load-and-Clear 1 Bit #define PTA2_CLR   (void) (*((volatile unsigned char *) (0x48000000 + (2<<21) + 0xF000))) #define PTA2_CLR_I   (void) (*((volatile unsigned int *) (0x48000000 + (2<<21) + 0xF000))) 例: PTA2_CLR;     //效果是GPIOA2低电平        LAC1      第2位     GPIOA_PDOR地址的A0-A15 7, BME同时提取多个bit，Unsigned Bit Field Extract 前8位内                     //UBFX      第1位开始       取1+1位   GPIOA_PDOR地址的A0-A18 #define PTA_OUT    *((volatile unsigned char *) (0x50000000+ (1<<23) + (1<<19) + 0xF000)) 前16位内                   //UBFX      第1位开始       取1+1位   GPIOA_PDOR地址的A0-A18 #define PTA_OUT_I    *((volatile unsigned int *) (0x50000000+ (1<<23) + (1<<19) + 0xF000)) 例: 初始值GPIO_PDOR = 0x3a;   //            11_1010   temp = PTA_OUT; //                    此时temp = 0x01 例: 初始值GPIO_PDOR = 0x35;   //            11_0101   temp = PTA_OUT; //                    此时temp = 0x02 该宏定义UBFX功能是将GPIO_PDOR从bit1开始提取1+1位，并以bit1为最低位赋值到目标变量。          需要注意的是UBFX与BFI一样操作的都是映射内存空间，用来操作GPIO时要以F000为起始地址。         BME执行的是读-修改-写操作，而我们很多寄存器有些位是w1c，也就是所谓的write-1-clear，写1清0的工作方式。使用BME时就需要特别注意和小心了，否则会出现很多不可预料的后果。               如果一个寄存器中有多个连续的W1C位，我们就不要使用LAS1来对寄存器写1清0了，因为在LAS1这个操作中，其中有一步操作是将数据读回（在reference manual中有read data return to core一说）。这一步会将原本不需要清0的位给清了。         下面介绍这个情况的实验。 在我们M0+的PWM模块中，寄存器TPM0_STATUS所有有效位都为w1c，我们模拟一个情景： 系统48MHz，TPM时钟128分频，TPM0定时中断计数器最大值为37499，并使能溢出中断。 通道0设置为output compare模式的match output low，比较值为10000，不触发中断。 通道1设置为output compare模式的match output high，比较值为20000，不触发中断。 上面的设置可以使我们每50ms进入一次中断，需要我们在中断服务程序中清中断标志。 TPM0_STATUS 地址为 0x4003_8050 中断函数中设置断点观察TPM0_STATUS的值，为1_0000_0011 B #define TPM0_STATUS_LAS1   (void) (*((volatile unsigned int *) (0x4C000000| (1<<21) | 0x38050))) 中断程序中用TPM0_STSTUS_LAS1将bit1置1清0，得到的结果是TPM0_STATUS = 0，使用LAS1作用在该寄存器的其他位结果都一样。将其他不需要改动的位都清0了。     我们换种方式。 #define TPM0_ STSTUS_BFI *((volatile unsigned int *) (0x50000000 | (0<<23) | (8<<19) | 0x38050)) =0x001 中断里用BFI去修改该连续的w1c位，从bit0开始，长度为8+1位，执行TPM0_STSTUS_BFI后bit8和bit2仍为1， bit0已经被清0了。这确实是我们想要的效果。         此后我们遇上一个寄存器有多个连续w1c时，可以使用BFI的方式来改写寄存器w1c位的值，而位判断则采用UBFX的方式来提取该位域。 下面是针对比较器的CMP0_SCR寄存器操作的例程. CMP0_SCR是8bit的寄存器bit1和bit2是w1c #define CMP_SCR_CFR_CLR *((volatile unsigned char *) (0x50000000+ (1<<23) + (1<<19) + 0x73003)) =4 #define CMP_SCR_CFF_CLR *((volatile unsigned char *) (0x50000000 + (1<<23) + (1<<19) +0x73003)) =2              //           BFI                    第一位开始   1+1位          2对应bit2bit1为01          4对应bit2bit1为10 #define CMP_SCR_CFR    *((volatile unsigned char *) (0x50000000 + (2<<23) + (0<<19) + 0x73003)) #define CMP_SCR_CFF    *((volatile unsigned char *) (0x50000000 + (1<<23) + (0<<19) + 0x73003))             //            UBFX                分别是提取bit2和bit1的值 void CMP_Change(void) { If (CMP_SCR_CFR) { CMP_SCR_CFR_CLR; }                   If (CMP_SCR_CFF) { CMP_SCR_CFF_CLR; } }         总结，BME功能可以有效提高M0+的位操作性能并减少代码占用空间，但用于处理w1c位时要特别小心，总的来说BME是个好东西，在内核资源紧张的时候可以给用户提供一个精简代码的手段。

Recently I did a porting based on AN4370SW for a customer to support TWR-K20D72M, and with some modification in source code, header file and link file as well, it works well as expected. The following simple describes what I have done: 1.Copy the project file folder for K20D50M "AN4370SW\Source\Device\app\dfu_bootloader\iar_ew\kinetis_k20" and rename is as "kinetis_k20d70m" 2.Change the target settings as well as the flash loader. 3. Replace the header file for K20D50M and include it in derivative.h. The header file for K20D72M can be found from KINETIS_72MHz_SRC(http://cache.freescale.com/files/32bit/software/KINETIS_72MHz_SRC.zip?fpsp=1&WT_TYPE=Lab%20and%20Test%20Software&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=zip&WT_ASSET=Downloads&sr=9) 4.Modify the interrupt table in cstartup_M.s, which is more likely a K60's vertor table. 5.Search the code related with the macro "MCU_MK20D5", and add similar code snippet for K20D72M , You may easily find them by search the keyword "MCU_MK20D7". That code parts include initialization for MCG, and PIT0 and USB interrupt enablements, some definition in bootloader.h . 6. Copy the link file from K20D50M, and modify the PFLASH size,SRAM size and DFLASH size as shown below: Perform MassErase before programming . and then you may press the SW1 on TWR-K20D72M to select which mode to enter after download the application firmware: pressing SW1 to enter bootloader mode and releasing it to enter application mode. 7. Build image for this DFU bootloader. Actually the bareboard projects in KINETIS_72MHz_SRC can be used for that purpose, and only link file needs some modification to put the image starting from 0xA000, since exception table redirection has already been done in these projects. after that, user needs change some settings in the CW projects to use the new link file: and generate S19 file as the output as well as the map file: after compiling , you will have a xxx.afx.s19 file, but that is not the final format, we still need to transform it to bin format, and it can be done by a small tool in "C:\Program Files\Freescale\CW MCU v10.3\MCU\prog" There are some settings for this tool to transform the S19 file, by clicking Burner->Burner Dialog, you will see some option views, please set them as below: Referring to the above figure, maybe you would wonder how to set up the Origin and Length field, actually Origin is the value where the image starts from just as the link file specified , and Length is calculated by the results from the map file. Please refer to the following figure for details. 0x3550 = 0x1c90 + 0x18c0. I also attached the burner's configuration file and image link file as well as the image for reference. Please copy the link file in "KINETIS_72MHz_SRC\build\cw\linker_files". Please kindly refer to the attachment for more details. Hope that helps, B.R Kan

  CNN on FRDM_K64 1 Introduction Limited by resources, ordinary MCU is difficult to do some complex deep learning. However, although it is difficult, it can still be done. CNN, convolutional neural network, is a kind of deep learning algorithm, which can be used to solve the classification task. After the implementation of CNN, ordinary MCU can also be used as edge computing device. Next, we introduce how to run CNN on frdm-k64 to recognize handwritten numbers. The size of digital image is 28x28. 28x28 image as input for CNN will output a 1x10 matrix. There are few deep learning libraries written for MCU on the Internet. Even if there are, there will be various problems. NNoM framework is easy to transplant and apply, so we use it     2 Experiment 2.1 Required tools: frdm-k64, python 3.7, Pip, IAR, tcp232   2.2 Download the source code of deep learning framework, https://github.com/majianjia/nnom This is a pure C framework that does not rely on hardware structure. Transplantation is very convenient   2.3  we select the example ‘bubble’ to add the Inc, port and Src folders in NNoM to the project, as shown in the figure          Figure 1 Open the file ‘port.h’ . The definitation of NNOM_LOG is changed to PRINTF (__ VA_ ARGS__ ）, Open the ICF file, and change the heap size to 0x5000, define symbol__ size_ heap__ = 0x5000; Malloc, which is used in this library, allocates memory from here. If it is small, it can't run the network   2.4 From the download framework, go into ‘mnist-simple/mcu’, which has trained file ‘weights.h’, and randomly generated handwritten image file, ‘image.h’. Add these two files to the project   2.5 Add headfile to ‘bubble.c’        #include "nnom_port.h" #include "nnom.h" #include "weights.h" #include "image.h"   2.6 Delete the original code, add the following code   nnom_model_t *model; const char codeLib[] = "@B%8&WM#*oahkbdpqwmZO0QLCJUYXzcvunxrjft/\\|()1{}[]?-_+~<>i!lI;:,\"^`'.   "; /*******************************************************************************  * Code  ******************************************************************************/ void print_img(int8_t * buf) {     for(int y = 0; y < 28; y++)        {         for (int x = 0; x < 28; x++)               {             int index =  69 / 127.0 * (127 - buf[y*28+x]);                      if(index > 69) index =69;                      if(index < 0) index = 0;             PRINTF("%c",codeLib[index]);                      PRINTF("%c",codeLib[index]);         }         PRINTF("\r\n");     } }   // Do simple test using image in "image.h" with model created previously. void mnist(char num) {        uint32_t predic_label;        float prob;        int32_t index = num;        PRINTF("\nprediction start.. \r\n");               // copy data and do prediction        memcpy(nnom_input_data, (int8_t*)&img[index][0], 784);        nnom_predict(model, &predic_label, &prob);          //print original image to console        print_img((int8_t*)&img[index][0]);               PRINTF("\r\nTruth label: %d\n", label[index]);        PRINTF("\r\nPredicted label: %d\n", predic_label);        PRINTF("\r\nProbability: %d%%\n", (int)(prob*100)); }   int main(void) {     uint8_t ch;     /* Board pin, clock, debug console init */     BOARD_InitPins();     BOARD_BootClockRUN();     BOARD_InitDebugConsole();     /* Print a note to terminal */     model = nnom_model_create();        // dummy run        model_run(model);     PRINTF("\r\nwhich image to distinguish？ 0-9 \r\n");     for(uint8_t i=0; i<10; i++)     {         print_img((int8_t*)&img[i][0]);     }     while(1)     {         PRINTF("\r\nwhich image to distinguish？ 0-9 \r\n");         ch = GETCHAR();         if((ch >'9') || ch < '0')         {             continue;         }         PRINTF("\r\n");         mnist(ch-'0');     } }   An error will be reported when compiling ‘weights.h’, due to lack of few parameters. In layer [1], layer [4], layer [7], you need to add ‘division (1,1)’ after ‘stride (1,1)’. In this way, the compilation passes.   2.7 As a result, open the serial port software. At the beginning, the terminal will print out a variety of handwritten digital pictures, and then enter a number, The corresponded picture will be recognized.                                                    Figure 2 When we input ‘8’, the recognition is the handwriting '9'                        Figure 3   The ‘Truth label’ corresponds to IMG9_LABLE in ‘image.h’ and ‘Predicted label’ is the prediction results   3 training Through the above steps, we have realized a simple handwritten numeral recognition. Next, we will introduce ‘weights.h’. How to generate the weight model here? The image data here are all from MNIST digital set. How can we make a handwritten number for MCU to recognize?   3.1 Under ‘nnom-master\examples\mnist-simple’, there is a ‘mnist_ simple.py’. You need to run it to generate ‘weights.h’ and ‘image.h’. To run this, you need to install tensorflow, keras and so on. When you run it, you can use pip to install what is missing The network operation process is as shown in the figure                               Figure 4 Conv2d-> convolution operation, Maxpool-> pooling. The meaning of convolution operation is to extract the features of the image. Pooling is a bit like compressing data, which can reduce the running space. 28x28 input and output a 1x10 matrix, representing the possibility of 0-9   3.2 We can use the ‘Paint’ program of WIN to adjust the canvas to 28x28, write numbers on it and save it in PNG format. I wrote a ‘4’     Figure 5   Change the code as following.   nnom_model_t *model; uint8_t temp[28*28]={0}; const char codeLib[] = "@B%8&WM#*oahkbdpqwmZO0QLCJUYXzcvunxrjft/\\|()1{}[]?-_+~<>i!lI;:,\"^`'.   "; /*******************************************************************************  * Code  ******************************************************************************/ void print_img(int8_t * buf) {     for(int y = 0; y < 28; y++)        {         for (int x = 0; x < 28; x++)               {             int index =  69 / 127.0 * (127 - buf[y*28+x]);                      if(index > 69) index =69;                      if(index < 0) index = 0;             PRINTF("%c",codeLib[index]);                      PRINTF("%c",codeLib[index]);         }         PRINTF("\r\n");     } }     void mnist_pic(uint8_t *temp) {        float prob;     uint32_t predic_label;        PRINTF("\nprediction start.. \r\n");          // copy data and do prediction        memcpy(nnom_input_data, (int8_t*)temp, 784);        nnom_predict(model, &predic_label, &prob);          //print original image to console        print_img((int8_t *)temp);        PRINTF("\r\nPredicted label: %d\n", predic_label);        PRINTF("\r\nProbability: %d%%\n", (int)(prob*100)); }   int main(void) {     /* Board pin, clock, debug console init */     BOARD_InitPins();     BOARD_BootClockRUN();     BOARD_InitDebugConsole();     /* Print a note to terminal */     model = nnom_model_create();        // dummy run        model_run(model);     while(1)     {         PRINTF("\r\n Send picture by serial\r\n");            DbgConsole_ReadLine(temp,784);         PRINTF("\r\n Got picture\r\n");           mnist_pic(temp);     } }   3.3 Then use pic2mnist.py(see the attachment), run this script with CMD and enter 'Python pic2mnist.py 1. PNG ', 1. PNG is the image to be parsed, and then ‘content.txt’ will be generated. The file contains the data of the picture. Send the data to the MCU through the serial port. Note that ‘Send as Hex’ should be checked. Similarly, the handwritten picture will be displayed first, and then the picture will be recognized.                                                           Figure 6   We can see that '4' was identified

On behalf of EarlOrlando​ Hello community, This document is intended to be a basic guide to get started with the eGUI. If you need a closer view about what this driver is, it is recommended to take a look into the eGUI Introduction document. Before starting, it is needed to download the library from the NXP eGUI website and it is recommended to take a look into the eGUI Reference Manual. For this document, a demo included in the eGUI drivers will be run and then modified to toggle a LED in the TWR-K70F120M board from the eGUI interface displayed in the TWR-LCD-RGB board. Contents. Introduction. 1. About this document. 2. Running the K70 demo on IAR. a. Compiling the TWR-K70F120M MQX libraries. b. Adding the SD card content. c. Download the application to the MCU. 3. Modifying the eGUI demo. a. Creating a new screen. i. Adding a new source file for the new screen. ii. Adding the screen header files. iii. Adding some macro definitions. iv. Defining screen attributes. v. Declaring the screen. vi. Defining a new string. vii. Adding the screen interfaces b. Opening the new screen. c. Creating a new button. d. Toggling the LED. 4. Conclusion. I hope you find this guide useful. Enjoy this guide, any feedback is welcome!

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 

    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.

ROM Bootloader KL43 chip with Kinetis Bootloader residing in the on on-chip read-only memory (ROM), can interface with USB, I2C, SPI, and LPUART peripherals in slave mode and respond to the commands sent by a master (or host) communicating on one of those ports. When KL43 chip with a blank flash, the Kinetis bootloader will execute automatically. Once the flash is programmed, the value of the FOPT field at Flash address0x40D will determine if the device boots the ROM bootloader or the user application in flash. The FTFA_FOPT [BOOTSRC_SEL] will select if boot from customer application (Flash) or boot from ROM bootloader. For example:       When Flash address 0x40D value is 0xFF, boot source is ROM bootloader;       When Flash address 0x40D value is 0x3D, boot source is Flash (Customer application). There with hardware pin(/BOOTCFG0) to control if boot from user application or ROM bootloader with FTFA_FOPT[BOOTPIN_OPT] bit . When FTFA_FOPT[BOOTPIN_OPT]  = 0, it forces boot from ROM if /BOOTCFG0 pin set to 0. blhost utility application The blhost utility is an example host program used to interface with devices running the Kinetis bootloader. The blhost application is released as part of Kinetis bootloader release package available on www.freescale.com/KBOOT . The blhost application default located at C:\Freescale\FSL_Kinetis_Bootloader_1_1_0\bin\win folder. About how to use blhost application, please check KBLHOSTUG document for more detailed info. Call Rom Bootloader from customer application In general, if customer application was programmed, the boot option should be change to Boot from Flash. If customer want to call the ROM bootloader during the application running, customer can refer below example. Set a signal for application code to call the ROM bootloader, such as press a button. In this demo, we use FRDM-KL43Z board SW3 (PTC3) to call the ROM bootloader. //Initalize PTEC3 as GPIO button PORT_Init (PORTC, PORT_MODULE_BUTTON_MODE, PIN_3, 0, NULL); GPIO_Init (GPIOC, GPIO_PIN_INPUT, PIN_3); The bootloader entry point for customer application to call the ROM bootloader.  //prototype of the entry point definition void run_bootloader(void * arg); //Variables uint32_t runBootloaderAddress; void (*runBootloader)(void * arg);   // Read the function address from the ROM API tree. runBootloaderAddress = **(uint32_t **)(0x1c00001c); runBootloader = (void (*)(void * arg))runBootloaderAddress; in <main.c> routine to call the ROM bootloader:   while (1)   {     if ((GPIOC_PDIR & (1 << 3)) == 0)     {       // Start the bootloader. runBootloader(NULL);     }   } Press SW3 button of FRDM-KL43Z board will call ROM bootloader.  Customer could continue to debug the code until the ROM bootloader be called. If customer debug into the runBootloader(NULL) function, there will stop at fixed address: 0x1C00_00C0. In fact, during call the ROM bootloader function , there will setting some parameters and then reset the KL43. When KL43 back from reset, it will boot from ROM bootloader. That reset will cause debugger disconnect with the KL43 product. More detailed info, please check attached demo code. BTW: The demo project is [frdm_led_test] inside of KL43 baremetal sample code, which could be downloaded from here.

Hi, all The default AN2295 UART bootloader doesn't work well on K21/other Kinetis because of using FEI and complicated autocalibration mechanism. I made a simple version to make it works on MK21DX128VMC5, FYI. Readm.txt: UART bootloader for K21. (Default is MK21DX128VMC5) 128KB_Pflash_64KB_Dflash.icf is application link script example for MK21DX128 used together with UART bootloader, UART bootloader use 0x0 - 0xFFF. Q: Why need this patch? A: The original AN2295 use internal RC and FLL output as system clock. The calibration mechanism is not stable. The main change of this patch is to use external cystal plus PLL as system clock to communicate with PC software. Changes to AN2295 1) Add MK21D5.h for K21 support 2) Add AN2295_TWR_K21_cfg.h for K21 support(Copy from AN2295_TWR_K60_cfg.h) 3) AN2295_TWR_K21_cfg.h    1> #define KINETIS_MODEL K21_50MHz    2> #define KINETIS_FLASH FLASH_128K    3> #define BOOT_UART_BASE UART2_BASE_PTR       #define BOOT_UART_GPIO_PORT PORTE_BASE_PTR       #define BOOT_UART_GPIO_PIN_RX   17       #define BOOT_UART_GPIO_PIN_TX   16    4> #define BOOT_PIN_ENABLE_NUM        7 4) Add mcg folder and mcg.c/mcg.h 5) kinetis_params.h:    1> Modify SRS_REG/SRS_POR_MASK/INIT_CLOCKS_TO_MODULES to meet MK21D5.h    2> Add PORT_PCR_PS_MASK for BOOTLOADER_PIN_ENABLE_INIT to enable Pull-up. 6) bootloader.h: #define BOOT_WAITING_TIMEOUT 500. PC software can't communicate to bootloader if only 1s delay. 7) bootloader.c:    1> #include "mcg.h"    2> Use 25MHz PEE:       SIM_CLKDIV1 = ( 0    | SIM_CLKDIV1_OUTDIV1(1)                            | SIM_CLKDIV1_OUTDIV2(1)                            | SIM_CLKDIV1_OUTDIV4(1));             (void)pll_init(8000000,       /* CLKIN0 frequency */                      LOW_POWER,     /* Set the oscillator for low power mode */                      CRYSTAL,       /* Crystal or canned oscillator clock input */                      4,             /* PLL predivider value */                      25,            /* PLL multiplier */                      MCGOUT);       /* Use the output from this PLL as the MCGOUT */    3> Restore to FEI mode before jump to Application:       pee_pbe(8000000);       pbe_fbe(8000000);       fbe_fei(32768); Knowing issues: 1) Don't use virtualCOM from OSJTAG, it's very hard to communicate with PC software. Use RS232 in TWR-SER2. 2) BOOTLOADER_CRC_ENABLE must be 0, otherwise PC software will report unknown protocol version

Introduction: User can modify the value of internal reference clock (IRC) by using the Trimming capability of programmers. There are two registers (ICS_C3 & ICS_C4) which contains the trim and fine trim value of the clock respectively. By default, devices comes with a factory programmed trim value which is automatically passed into these registers during reset initialization when not in debug mode. These registers needs to be passed with appropriate value to get the required clock value. This is where programmers come into picture, they generally have this capability to find the accurate trim and fine trim values corresponding to required clock. Now the catch here is that the customized trim value calculated by programmers is stored at reserved flash location (eg-0x000003ff and 0x000003fe for Ke02) and have to be copied to trim registers( ICS_C3 &C4) manually by user during code initialization. Using this process to trim the clock will give accurate desired clock without any deviation between samples. Process:  There is an option in programmers( like I am using PEmicro Multilink universal ) for enabling and setting the trimming feature in the configuration settings as below:         After enabling this option, the programmer will find the best trim value and store at internal memory location:   0x03ff for trim internal reference value 0x03fe for fine trim internal reference value   Below snapshot from console shows this process:       Next step is to copy these value from above locations and pass it to ICS_C3 and ICS_C4 manually in our application code. You can use below code lines:       ICS->C3 = *((uint8_t*) 0x03FF); // trim internal reference clock     ICS->C4 |= ICS_C4_SCFTRIM(*((uint8_t*) 0x03FE)); // fine trim internal reference clock   What the above logic does is – it copies the trimmed value from the factory programmer into your ICS register – not dependent on a constant value but dynamically update the register as per the tuning happening by the programmer. Similar option is there in production programmers also to take care of the trimming process. Note: Above steps are with reference to KE series, for other series user has to check the device reference manual for specific address and register. Also attaching a code with the above mentioned things added into it for ease of understanding. Thanks Madhur

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

Introduction Even with the prevalence of universal asynchronous receiver/transmitter (UART) peripherals on microcontrollers (MCUs), bit banged UART algorithms are still used.  The reasons for this vary from application to application.  Sometimes it is simply because more UARTs are needed than the selected device provides.  Maybe application or layout restrictions require certain pins to be used for the UART functions but the device does not route UART pins to the required package pins.  Maybe the application requires a non-standard or proprietary UART scheme. Whatever the reason, there are applications where a bit banged UART is used and is typically a pure software implementation (a timer is used and the MCU core controls a GPIO pin directly).  A better alternative may be to use Flextimer (FTM) or Timer/PWM Module (TPM) to take advantage of the features of these peripherals and possibly offload the CPU.  This document will explain and provide a sample application of how to emulate a UART using the FTM or TPM peripheral.  A Kinetis SDK example (for the TWR-K22F120M and FRDM-K22F platforms) and a baremetal legacy code example (for the FRDM-KL26Z) are provided here. UART protocol Before creating an application to emulate a UART, the UART protocol and encoding must be understood. The UART protocol is an asynchronous protocol that typically includes a start bit, payload (of 7-10 data bits), and a stop bit but does allow for many variations on the number of stop bits and what/how to transfer the data.  For this document and application example, the focus will be UART transmission that follows 1 start bit, 8 data bits, 1 stop bit, no parity, and no flow control.  The data will be transmitted least significant bit (LSB) first.  The following image is a block diagram of this transmission. However, this doesn't specify what the transmission looks like electrically. The figure below shows a screenshot of an oscilloscope capture of a UART transmission.  The data transmitted is 0x55 or a "U" in the ASCII representation. Notice that the transmission line is initially a logic high, and then transitions low to signal the start of the transmission.  The transmission line must stay low for one bit width for the receiver to detect it.  Then there are 8 data bits, followed by 1 stop bit.  In the case shown above, the data bits are 0x55 or 0b0101_0101.  Remember that the transmissions are sent LSB first, so the screenshot shows 1-0-1-0-1-0-1-0.  The last transition high marks the beginning of the stop bit and the line remains in that state until the start of the next transmission.  The receiver, being asynchronous, does not require any type of identifying transition to mark the end of the stop bit. FTM/TPM configuration The first question many may ask when beginning a project like this is "How do I configure the FTM/TPM when emulating a UART".  The answer to this depends on the aspect of this problem you are trying to solve.  Transmitting and receiving characters require two different configurations.  Transmission requires a configuration that manipulates the output pin at specific points in time.  Receiving characters requires a configuration that samples the receive pin and measures the time between pin transitions.  The FTM and TPM have the modes listed in the following table: The FTM and TPM have four different modes that manipulate an output:  Output compare (no pulse), Output compare (with pulse), Edge-aligned PWM, and Center-aligned PWM.  Neither PWM mode is ideal for the requirements of the application.  This is because the PWM modes are designed to produce a continuous waveform and are always going to return to the initialized state once during the cycle of the waveform.  However, the UART protocol may have continuous 1's or 0's in the data without pin transitions between them. The output compare mode (high-true or low-true pulse modes) is designed to only manipulate the pin once, and only produces pulses that are one FTM/TPM clock cycle in duration.  So this is obviously not desirable for the application.  The output compare mode (Set/Clear/Toggle on match) is promising.  This mode manipulates the output pin every cycle.  There are three different options:  clear output on match, set output on match, and toggle output on match.  Neither "clear output on match" nor "set output on match" are ideal as either would require configuration changes during the transmission of a character.  The "toggle output on match", however, can be used and is the selected configuration mode for this sample application. To receive characters, there is only one mode that is intuitive:  "the input capture mode".  This mode records the timer count value on an edge transition of the selected input pin.  Similar to the output compare mode chosen for the transmit functionality, the input capture mode has three sub-modes:  capture on rising edge, capture of falling edge, and capture on either edge.  It is clear from the descriptions that capture on either edge should be selected. Transmit encoding The selection of the FTM/TPM mode is moderately intuitive, but using this mode to emulate a UART transmission is not.  There are two issues that make this a little tricky. 1) The output pin is initialized low. However, the UART protocol needs the pin to begin in a logical high state. 2) The pin transitions on every cycle provided the channel value is less than the value of the MOD register. Due to continuous strings of 1's or 0's, it is necessary to have periods where the pin does not transition. Both of these points have workarounds. Output pin initialization For the first issue, the channel interrupt is first enabled and the channel value register is loaded with a value much less than the value in the MOD register.  Then in the channel interrupt service routine, the pin is sampled to ensure that it is in the logic high state and the channel interrupt is disabled (and will not be re-enabled throughout the life of the application).  The code for this interrupt service routine is as follows. Output pin control For the second issue, a method of not transitioning the pin value while allowing the timer to continue counting normally is necessary.  The Output Compare mode uses the channel value register to determine when the pin transition occurs.  If a value greater than MOD is written to the channel value register, the channel value will never match the count register and thus, a pin transition will never occur.  So, when a series of continuous 1's or 0's need to be transmitted, a value greater than the value in the MOD register can be written to the channel value register to keep the output pin in its current state. However, when a value greater than MOD is written to the channel value register, no channel match will occur (which means channel interrupts will not occur).  So the timer overflow interrupt must be used to continue writing values.  This requires the updates to be output pin to be planned ahead of time and makes the transmission algorithm a little tricky.  The following diagram displays when which values should be written to the channel value register at which points in time to generate the appropriate pulses. Writing a function to translate a number into the appropriate series of MOD/2 and MOD+1 values can be a little tricky. To do this, we must first notice that MOD/2 needs to be written when changes on the transmission pin are need and MOD+1 needs to be written when pin transmissions are not desired.   So, what logical function can we use to determine when a change has happened?  XOR is the correct answer.  So what two values need to be XOR'd together?  One value is obviously the value that we want to send.  But what is the second value?  It turns out that the second value is a shifted version of the value that we want to send.  Specifically, the second value is the desired value to send shifted to the left by one.  (You can think of it as sort of a "future" value of the desired value).  The following pictures show how to determine the queue to use for the transmission. Receive decoding The receive functionality has an advantage over the transmit functions in that it is possible to use DMA for the reception of characters.  This is because the receive function takes advantage of the input capture functionality of the FTM / TPM and therefore can use the channel match interrupt.  The example application provided with this document implements a DMA method and a non-DMA method for reception. First, the non-DMA method will be discussed. Before discussing the specifics of gathering the input pulse widths, some details of the receive pin need to be discussed. Detecting the start bit The receive pin needs to be able to determine when the start of the packet transmission begins.  To do this, the receive pin is configured as an FTM / TPM pin. At the same time, the GPIO interrupt functionality is configured on the same pin for a falling edge interrupt.  The GPIO interrupt capabilities are enabled in any digital mode, so the GPIO interrupt will still be able to be routed to the Nested Vector Interrupt Controller (NVIC).  The pin interrupt is used to start the FTM / TPM clock when a new character reception begins. In the GPIO interrupt for this pin, the FTM / TPM counter register is reset and the clock to the FTM / TPM is turned on.  The code for the GPIO interrupt service routine is shown below.  Receiving characters without DMA Now, when receiving characters and not using DMA, the first thing to understand is that the Interrupt Service Routine (ISR) will be used and it will mainly be used to record the captured count values.  The interrupt service routine also tracks the current receive character length and resets the counter register.  This is so that the values in the receive queue reflect the time since the last pin transition.  The interrupt function for the non-DMA application is shown below. Notice that the first two actions in the ISR are resetting the count register, and clearing the channel event interrupt flag.  Then the channel value is stored in the receive pulse width array (this is simply an array that holds the receive pulse widths of the current character being received).  Next, recvQueueLength, the variable which holds the current length of the character being received, is updated to reflect the latest character length.  The next step is to determine if the full character has been received.  This is determined by comparing recvQueueLength to the RECV_QUEUE_THRESH, which is the threshold as determined by multiplying the number of expected bits by the expected bit width plus another bit width (for the start bit).  If the recvQueueLength is greater than the RECV_QUEUE_THRESH, then a semaphore is set, recvdChar, to indicate that a full character has been received.  The FTM / TPM clock is turned off, and the pin interrupt functionality of the receive pin is enabled.  The final step in the interrupt routine is to increment the receive queue index, recvQueueIndex.  This variable points to the current entry in the receive queue array. Using DMA to receive characters When using DMA, the receive FTM / TPM interrupt is much different. The interrupt routine simply needs to clear the channel interrupt flag, stop the FTM / TPM timer, disable the DMA channel, and set the received character semaphore.  The character is then decoded outside of the interrupt routine.  The interrupt function when using DMA is shown below: Decoding the received pulse widths Once the array of pulse widths has been populated, the received character needs to be translated into a single number.  This varies slightly when using DMA and when not using DMA. However, the basic principle is the same.  The number of bits in a single entry is determined by dividing by the expected bit width and this is translated into a temporary array that contains 1's and 0's, and then that is used to shift in the appropriate number of 1's and 0's into the returned char variable.  A temporary array is needed because the values are shifted into the UART LSB first, so the bit must be physically flipped from the first entry to the last.  There is no logical operation that will do this automatically. The algorithm to perform this translation is shown below.  In this algorithm, note that recvPulseWidth is the array that contains the raw count value of the pulse width.  The array tempRxChar holds the decoded character in reverse order and rxChar is a char variable that holds the received character. Conclusion This document provides an overview of the UART protocol and describes a method for creating a software UART using the timing features of the FTM or TPM peripheral.  This method allows for accurate timing and while not relying entirely on the CPU and the latency associated with the interrupt and the GPIO pins.  The receive function is open to further optimization by using DMA, which can provide further unloading of the CPU.

       所谓“知识产权保护”，其实就是在产品量产之后防止其芯片内部代码通过外部调试器被有效读取出来的手段，毕竟现在来说硬件电路是比较容易被复制的，如果软件再不设防的话，在山寨技术如此发达的今天（用发达来形容貌似不是很过分吧，呵呵）这个产品估计很快就会被淘汰了。        因为最近有很多客户问到关于Kinetis的加密锁定问题，所以我觉着还是有必要对其细说说的。其实飞思卡尔对于知识产权保护方面还是做了很大的功夫的，而且使用起来也是比较方便的（这点很重要），具体可以参考Kinetis的Reference Manual中Security这一章，这里我就以在IAR环境下锁定K60为例介绍一下使用方法： 1. 首先简单介绍一下原理，即如果将K60置于Security状态（即锁定状态），则是不能通过Debug接口或者EzPort接口对芯片内部flash有任何操作的（CPU还是可以正常读写flash的，也就是说程序还是可以正常运行的，只不过是不能被外部非法读取了），当然“mass erase”命令除外（我们平时在Jlink Command窗口中敲入的unlock Kinetis命令就是触发这个命令给芯片的），通过“mass erase”命令可以再次将芯片擦除到出厂状态（即unsecure解锁的过程），这样芯片就又可以正常使用了（方便用户之后的程序升级）。咳咳，不过不用担心，解锁之后的芯片其内部的flash已经被完全擦除掉变为空片状态，也就是说内部的代码已经没有了，所以。。。懂的。。。呵呵； 2. 说完Security的原理，下面再聊聊K60实现security的process。我们可以通过K60的FTFL_FSEC寄存器中的SEC位来设定芯片的security状态，如下图所示，芯片默认出厂状态SEC位是为10的，即非加密锁定的，而如果将SEC位设定为00、01或者11任何一种情况，则芯片都将处于锁定状态（这就是我们接下来要干的事了，呵呵）。这里可能会有人疑问，在这个寄存器在重新上电之后会保存内容吗，我只能说“咳咳，都能抢答了”，哈哈，这正是我下面要说的； 3. K60在flash中0x00000400~0x0000040F这16个字节范围的地址定义为寄存器加载地址（Flash配置区），如下图所示，而这其中0x0000040C的地址内容在芯片上电之后会被自动加载到FTFT_FSEC寄存器中，也就是说我们只需要在烧写程序的时候把相应数据写到该flash地址即可在上电之后对芯片进行加密锁定，由此实现加密锁定。 4. 好了，原理和process都说完了，准备工作就做好了，下面就撸胳膊抹袖子开工干活吧，呵呵。其实飞思卡尔已经为我们做好了相关工作，只不过我们平时因为用不到没有注意到罢了。我们打开IAR环境，然后导入需要加密的代码工程，再打开工程目录下cpu文件组中的vectors.c和vectors.h（如果你的工程架构类似于飞思卡尔官方的sample code的话就在这个路径下）。在vectors.h里的最后部分我们会看到4个config段（共16个字节大小），如下图1，这四个段就是定义了上述0x400~0x40F的内容，其中CONFIG_4中最后的0xfe即为0x40C地址的内容（注意ARM处理器默认是little end模式的，所以0x40C在低地址），0xfe表明SEC位为10，即非加密状态，这样如果我把该0x40C地址的内容改成0xfc、0xfd或者0xff任意一个都可以实现对芯片的加密锁定。至于该四个配置段定义是如何映射到K60的flash区中的呢，去vectors.c文件中中断向量表vector_table[]的最后看看就知道了，如下图2； 5. 这里我们选择将CONFIG_4内容由原来的0xfffffffe改成0xfffffffd即可，然后保存编译通过之后，在查看其生成的s19文件中可以看到如下图所示，即0x40C地址的内容被修改成了0xfd，这样烧写文件就搞定了； 6. 当然到这一步实际上还没有完，其实在IAR的新版本之后（IAR6.6之后），其自带的flashloader默认是把0x400~0x40F这段保护起来的（防止误操作对芯片意外的security），即使如上面所述修改好相应内容，在烧写的过程中flashloader也不会对这段地址的内容做任何擦除和写入。为此还需要再额外对IAR的flashloader进行配置，具体步骤如下： （1）进入Options->Debugger->Download，选择如下： （2）点击“OK”，然后系统会提示保存该修改后的flashloader配置，建议把自己修改好的.board文件保存到自己的工程目录下，方便以后直接调用该flashloader。 7. 至此全部设置就搞定了，点击编译连接，然后下载，即可把加密后的代码烧写到芯片的flash里面去了。注意如果我们点击调试按钮的话，一旦程序烧进去之后调试器会自动复位芯片，此时加密状态位会被load到FTFT_FSEC[SEC]位中，芯片的调试端口就会被停掉，所以这时进入不到调试界面，而是弹出错误窗口，不用担心，因为此时程序已经正确烧到芯片中，我们重新插拔电源之后会看到程序已经正常执行，而此时的芯片已经处于加密状态。当然如果我们想再进入调试模式调试芯片的话，一种是通过Jlink Command窗口解锁，如下图1，另一种是再次点击调试按钮，会弹出解锁窗口，点击解锁即可，如下图2。 图1 图2

Hi All, NXP provides a software drivers library for Kinetis M devices, the KM bare-metal drivers. It includes support for peripherals and FreeRTOS. Follow the instructions to download and install the software package. Go to the KM3x section in the NXP webpage. Click on the documentation tab In the Application Notes section look for the API reference manual for Kinetis M bare-metal drivers and software examples, download: HTML > Reference Manual and documentation ZIP > Software package Unzip the KMSWDRVAPIRM_SW.zip file into a computer location. Inside the folder you will find several .exe files, select the appropriate file for your application and follow the installation instructions. By default a folder named KMxxxSWDRV_Rx_x_x is created. You can see the folder structure like this build: Build examples project files for the selected IDE. refman: Source files of the HTML Reference Manual src: Source files for drivers: common – common files for projects: device headers, startup routines, etc. drivers – peripheral drivers source code. freemaster – Freemaster source files for communication functions with Freemaster software. freertos – FreeRTOS files, kernel and RTOS support. projects – example projects demonstrating peripherals and modes. toolchain – toolchain support. template – Base projects for supported IDEs and make_project.exe file to create new project for different supported IDEs. If you need support for a different IDE or KM device you just need to extract the appropriate .exe file from the SW package. Hope information helps! Happy Downloading and installing! Regards, Adrian Cano NXP FAE