Abstract MK60 is a popular MCU in Kinetis K family. NXP has prepared some kinds of bootloader for TWR-K60D100. But as we all know, MCUBoot2.0.0 is the most update bootloader for Kinetis family. It is a configurable flash programming utility that operates over a serial connection on Kinetis MCUs. It enables quick and easy programming of Kinetis MCUs through the entire product life cycle, including application development, final product manufacturing, and beyond. But sinceTWR-K60D100 is a relatively old platform compare to K22 and K64/K65/K66, MCUBoot2.0.0 did not add MK60 to its target board. If customer don’t like those old bootloader, they have to port it by themselves. This article tries to guide user to port MCUBoot to TWR-K60D100 base on Chapter 10 in Kinetis Bootloader v2.0.0 Reference Manual. This time we use KDS. Software requirement: Kinetis Design Studio 3.2 MCUBootloader 2.0.0 (KBoot 2.0.0) MCUXpresso Config Tools v4.0 SDK_2.2_TWR-K60D100M Porting flow Step 1: First I copy NXP_Kinetis_Bootloader_2_0_0\targets\MK64F12 to NXP_Kinetis_Bootloader_2_0_0\targets\MK60D100. The reason I select MK64 is more likely to MK60 than other target, especially in clock distribution, system integration module and signal multiplexing. In mk60d100\src directory, rename the following files: clock_config_mk64f12.c —> clock_config_mk60d100.c hardware_init_mk64f12.c —> hardware_init _ mk60d100.c memory_map_mk64f12.c —> memory_map _ mk60d100.c peripherals_ mk64f12.c —> peripherals _ mk60d100.c Then copy system_MK60D10.c and system_MK60D10.h from SDK_2.2_TWR-K60D100M to mk60d100\src\startup, copy startup_MK60D10.S from SDK_2.2_TWR-K60D100M to mk60d100\src\startup\gcc. Step 3: Then I copy \src\platform\devices\MK64F12 to \src\platform\devices\mk60d100, copy SDK_2.2_TWR-K60D100M\devices\MK60D10\fsl_device_registers.h, MK60D10.h, and MK60D10_features.h to this new directory. Step 4: Open the KDS project in MK60D100 and replace above old file with new file. After that, I change some setting. Figure 1. Target Processor change   K64 has hardware FPU, but K60D100 hasn’t. So, Float ABI must be changed to software. There is a C/C++ preprocessor define that is used by the bootloader source to configure the bootloader based on the target MCU. This define must be updated to reference the correct set of device-specific header files. Figure 2. Preprocessor change   As to the link file, it needn’t to be change. We can use K64’s link file. TWR-K60D100 use an old version PE debugger. So, the debugger setting must be changed. Figure 3. Debug setting Step 5: MK60’s clock distribution structure is different with MK64. We must modify this part. As it is very complex, use MCUXpresso Config Tools to generate this config code is a sensible choice. Open the tools and step clock structure as below: Figure 4. clock setting After that, generate the code and save them to \src\platform\devices\mk60d100. Since MCUBoot2.0.0 is not base on SDK2.x, we must copy some related driver file from SDK2.x package, include fsl_smc.c, fsl_smc.h, fsl_rtc.c, fsl_rtc.h. Then add them to project. In clock_config_mk60d100.c line 168, the code is clock_mode_switch(s_currentClockMode, kClockMode_FEI_48MHz); Replace it with:      BOARD_BootClockUSB(); // this function was generated by MCUXpresso Config Tool Then add the head file of “clock_config.h”.   Step 6: TWR-K60D100 use UART5 as the debug UART port. Please refer to https://community.nxp.com/docs/DOC-340954 for detail. MCUBootloader2.0.0 do not support UART5. User must add its code in pinmux_utility_common.c.   Step 7: Modify usb_clock_init() in hardware_init_MK60D100.c as below bool usb_clock_init(void) {    SIM->SCGC4 &= ~SIM_SCGC4_USBOTG_MASK;      SIM->CLKDIV2 = (uint32_t)0x00L;    SIM->SOPT2 |= SIM_SOPT2_USBSRC_MASK | SIM_SOPT2_PLLFLLSEL(0x01);     //k60 PLLFLLSEL change from 3 to 1      SIM->SCGC4 |= SIM_SCGC4_USBOTG_MASK;   //   USB0->CLK_RECOVER_IRC_EN = 0x03; //   USB0->CLK_RECOVER_CTRL |= USB_CLK_RECOVER_CTRL_CLOCK_RECOVER_EN_MASK;   //   USB0->CLK_RECOVER_CTRL |= 0x20;      return true; }   Modify memory_map_MK60D100.c as below: memory_map_entry_t g_memoryMap[] = {    { 0x00000000, 0x0007ffff, kMemoryIsExecutable, &g_flashMemoryInterface },   // Flash array (512KB)    { 0x1fff0000, 0x2000ffff, kMemoryIsExecutable, &g_normalMemoryInterface }, // SRAM (256KB) { 0x40000000, 0x4007ffff, kMemoryNotExecutable, &g_deviceMemoryInterface }, // AIPS peripherals      { 0x400ff000, 0x400fffff, kMemoryNotExecutable, &g_deviceMemoryInterface }, // GPIO    { 0xe0000000, 0xe00fffff, kMemoryNotExecutable, &g_deviceMemoryInterface }, // M4 private peripherals    { 0 }                 // Terminator };   Modify bl_uart_irq_config_common.c as below: void UART_SetSystemIRQ(uint32_t instance, PeripheralSystemIRQSetting set) {    switch (instance)    {        case 0: #if (FSL_FEATURE_SOC_UART_COUNT > 1)        case 1: #endif // #if (FSL_FEATURE_SOC_UART_COUNT > 1) #if (FSL_FEATURE_SOC_UART_COUNT > 2)        case 2: #endif // #if (FSL_FEATURE_SOC_UART_COUNT > 2) #if (FSL_FEATURE_SOC_UART_COUNT > 3)        case 3: #endif // #if (FSL_FEATURE_SOC_UART_COUNT > 3) #if (FSL_FEATURE_SOC_UART_COUNT > 4)        case 4: #endif // #if (FSL_FEATURE_SOC_UART_COUNT > 4) #if (FSL_FEATURE_SOC_UART_COUNT > 5)          // add UART5 support        case 5: #endif // #if (FSL_FEATURE_SOC_UART_COUNT > 5)              if (set == kPeripheralEnableIRQ)            {                NVIC_EnableIRQ(uart_irqs[instance]);            }            else            {                NVIC_DisableIRQ(uart_irqs[instance]);            }            break;    } }   In target_config.h, modify kMaxCoreClock value to 100.   Step 8: After all of the above work, compile the project and download to TWR-K60D100 board. You’ll find KinetisFlashTool.exe can recognize the device by UART. If you establish a Tower system with TWR-SER board, KinetisFlashTool can also recognize the device by USB.   Conclusion: K60 is the base of many Kinetis K series MCU, include K10, K20, K61, K70. If you want to port MCUBoot2.0.0 to these MCU, you just want to update the clock_config file.

  MCU Bootloader2.0.0 enables quick and easy programming of Kinetis MCUs through the entire product life cycle, including application development, final product manufacturing, and beyond. It supports many kinds of peripherals, include UART, I2C, SPI, USB, CAN and so on. Among these peripherals, UART is most common used. In reference manual, it only says that feature can be turned on or off by using #define statement in bootloader_config.h. In fact, you can use UART0 by default. But if you want to use other UART port, change TERM_PORT_NUM to other value is useless. If you traced this value, you’ll find it is not used at all, nor the TERMINAL_BAUD. Here we use FRDM-KV31F512 as the example. We want to download image by UART2. First, we should modify peripherals_pinmux.h. #define BL_ENABLE_PINMUX_UART2 (BL_CONFIG_SCUART)     //line 38   //! UART pinmux configurations #define UART2_RX_PORT_BASE PORTE #define UART2_RX_GPIO_BASE PTE #define UART2_RX_GPIO_PIN_NUM 17               // PIN 16 in the PTB group #define UART2_RX_FUNC_ALT_MODE kPORT_MuxAlt3   // ALT mode for UART0 RX #define UART2_RX_GPIO_ALT_MODE kPORT_MuxAsGpio // ALT mode for GPIO functionality #define UART2_RX_GPIO_IRQn PORTE_IRQn #define UART2_RX_GPIO_IRQHandler PORTE_IRQHandler #define UART2_TX_PORT_BASE PORTE #define UART2_TX_GPIO_PIN_NUM 16             // PIN 17 in the PTB group #define UART2_TX_FUNC_ALT_MODE kPORT_MuxAlt3 // ALT mode for UART0 TX   The original define is UART0, here we change it to UART2. It is strongly recommended to do so. Otherwise you’ll find that UART can’t work at all. Another comment here is PTE16 and PTE17 is conflict with SPI. You must disable SPI or change SPI function to other pins.   Next we must modify peripherals_KV31F512.h. const peripheral_descriptor_t g_peripherals[] = { #if BL_CONFIG_SCUART    // UART0    {.typeMask = kPeripheralType_UART,      .instance = 2, // change this value from 0 to 2      .pinmuxConfig = uart_pinmux_config,      .controlInterface = &g_scuartControlInterface,      .byteInterface = &g_scuartByteInterface,      .packetInterface = &g_framingPacketInterface },   Although there is a baud rate definition TERMINAL_BAUD, but it is never used too. MCU bootloader2.0.0 use auto baud rate detection. When power on, bootloader will go to autobaud detection mode. KinetisFlashTool sends ‘0x ’ every second. Bootloader check this byte and calculate baud rate.   After getting this value, bootloader will change to normal communication mode. Baud rate will not change until reset. If blhost is used, subsequent blhost invocations must specify the same baud rate as was used for the initial invocation unless the bootloader is reset. If the baud rate is not specified using the -p COMx, <baudrate> option, the UART baud rate will be set to 57600. Since Kinetis MCU UART module don’t have auto frequency detect function, the bootloader detects frequcny by software. It uses GPIO interrupt and timer to measure frequency. But in bootloader, there is only code for UART0, there isn’t code for other UART port. We must add the code. In hardware_init_KV31F512.c, modify the function get_uart_clock()   uint32_t get_uart_clock(uint32_t instance) {    switch (instance)    {        case 0:        case 1:            // UART0 and UART1 always use the system clock            return SystemCoreClock;        case 2:            return get_bus_clock();        default:            return 0;    } }   KV31 has 4 UART, include three UART modules and one low-power UART. They have different clock source. UART0 and UART1 use System clock while UART2 and LPUART0 use Bus clock. Thus， we finished the work. UART2 can work as the download port now.

First let us see the clock tree: Core clock up to 112M, Bus clock up to 56M, Flash clock up to 28M. Clock can been from: System OSC、Slow IRC 、Fast IRC and System PLL 1. OSC SCG_SOSCCFG 2. PLL configuration formula: SPLL_CLK = (VCO_CLK)/2 VCO_CLK = SOSC_CLK/(PREDIV + 1) *(MULT + 16)  3. SCG_SPLLCSR void SystemClockInit(void) { SCG->SOSCCFG = 0x3C; SCG->SOSCCSR |= 1<<0; /* SOSCEN=1 enable SOSC clock */ /*wait clock active*/ while((SCG->SOSCCSR & SCG_SOSCCSR_SOSCVLD_MASK) == 0); SCG->SPLLCSR &= ~(0x1<<0) ; /* SPLLEN=0: disable PLL*/ SCG->SPLLCFG &= ~(0x7<<8); /* PREDIV=0: 1 */ SCG->SPLLCFG |= 0xCU<<16; /* MULT=12: 28   PLL VCO = 8/1*(12+16) = 224M */ SCG->SPLLCSR |= 0x1<<0; /* SPLLEN=1: enable PLL */ /* wait PLL active*/ while((SCG->SPLLCSR & SCG_SPLLCSR_SPLLVLD_MASK) == 0); SCG->RCCR |= SCG_RCCR_DIVCORE(0); /* DIVCORE=0: 1, CORE/SYS_CLK  112MHz */ SCG->RCCR |= SCG_RCCR_DIVBUS(1); /* DIVBUS=1: 2, BUS_CLK  56MHz */ SCG->RCCR |= SCG_RCCR_DIVSLOW(3); /* DIVSLOW=2: 4   FLASH_CLK  is 28MHz */ SCG->RCCR &= 0xFEFFFFFF; /* Initially set to SIRC so that LSB could be set as '0' */ SCG->RCCR |= SCG_RCCR_SCS(6); /* SCS=6: system clock System PLL */ }

The AOI and Crossbar modules are inregrated in DSC, Kinetics KV and i.mxrt families, user can use them to generate complicated trigger signal for the on-chip peripherals. The DOC discusses the AOI function, crossbar fuction based on KV58. It gives the example, the example demos how to implement AND operation of two signals via crossbar switch A and B and AOI modules. The two logic signals are connected to the pads of KV58, and routed to AOI inputs via Crossbar switch B, the AOI sub-module0 implements the AND operation of the two signals, and output the AND output signal Event0  to pad of KV58 via crossbar switch A. Connect input pads and output pad of KV58 to oscilloscope, from the waveform of the three signals on scope, we can see that the AND logic  is implemented.

I’ve noticed some comments about Kinetis MCUs availability and status that I’d like to address for the entire community. The Kinetis MCU portfolio has seen significant growth in the mass market and is on track for continued strong growth in the coming years. Due to this growth, the demand on the Kinetis MCUs has outstripped the available supply, leading to extended leadtimes.  We have invested additional resources across the manufacturing line for 2018 and beyond to increase overall capacity and are pleased to be able to communicate that the lead time is being reduced from 39 weeks to low 30's this month.  It is anticipated there will be further reduction in Q3 2018 with a target of being back to a typical 12-14wk lead time in Q1 2019.  Additionally, we have increased our product longevity commitment on Kinetis K, L, E, V, M and W MCUs to 15 years to support the strong pipeline of design-in activity across the Kinetis portfolio that we are seeing in the market.  This document was generated from the following discussion: Kinetis Availability &amp; Longevity

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; }

How to byte program SPI flash via QSPI QSPI module are used in many Kinetis MCU, like K8x, K27/28 and KL8x. QSPI expands the internal flash range and can run in a fast speed. Compared to DSPI, QSPI is very complex and often takes a lot of time to learn. In KSDK there are two QSPI demo which shows how to program SPI flash in DMA mode and polling mode. Both of them program the QSPI flash with a word type array. But can the QSPI module program SPI Flash in byte? Yes, this article shows how to do it. Device: FRDM_KL82Z Tool: MCUXpresso IDE Debug firmware: JLINK I build the test project base on KL82 SDK/driver_example/qspi/polling_transfer. To byte program SPI flash, a new LUT item must be added. uint32_t lut[FSL_FEATURE_QSPI_LUT_DEPTH] =    {/* Seq0 :Quad Read */          /* CMD:       0xEB - Quad Read, Single pad */          /* ADDR:       0x18 - 24bit address, Quad pads */          /* DUMMY:     0x06 - 6 clock cyles, Quad pads */          /* READ:       0x80 - Read 128 bytes, Quad pads */        …        …        [32] = QSPI_LUT_SEQ(QSPI_CMD, QSPI_PAD_1, 0x02, QSPI_ADDR, QSPI_PAD_1, 0x18),        [13] = QSPI_LUT_SEQ(QSPI_WRITE, QSPI_PAD_1, 0x1, 0, 0, 0),        …        /* Match MISRA rule */        [63] = 0}; This item tells system how to program a single byte. Then when we write the data to TxBuffer, we must write the byte 4 times. This is because a write transaction on the flash with data size of less than 32 bits will lead to the removal of four data entry from Txbuffer. The valid bit will be used and the rest of the bits will be discard. Then before we start programming, we must set the data size.      QSPI_SetIPCommandSize(EXAMPLE_QSPI,1);   After byte program, we can see the result from 0x68000000. Attachment is the demo project. You can find that 0x03 was written to 0x68000005 after running.

This hint will demonstrate how to verify ADC conversion rate (with oscilloscope) during testing phase.   Refer to the phenomenon descripted in"Figure 1. Voltage drops at ADC input during sampling process" of AN4373. If too large values is selected for the external RC components, serious voltage disturbances (voltage drops/peaks) at the ADC input (see Figure 1) can be observed. The disturbance at the ADC input in this case results from the basic principle of operation of the sample and hold (S/H) circuit inherent in a SAR ADC. Although we should avoid this happening, but it can be used to measure the ADC conversion rate with oscilloscope during testing phase.   According to the 'Table 30. 16-bit ADC operating conditions' of K64P144M120SF5, we can know that the max ADC conversion rate is 818.330 ksps. Here I create an example by using KDS3.2 with Processor Expert(See the attach file). After select same configuration according to that table, I got almost the same ADC conversion rate. The conversion time meet equation given in Reference Manual too. Now let's measure the ADC conversion rate on FRDM-K64F board with oscilloscope. After connected an external 1.5KΩ resistance, the value of external RC components is big enough to be observed. Below is the waveform observed with oscilloscope, the frequency between voltage drops at ADC input during sampling is about 818 ksps. This test result is consistent with the theoretical calculated value.

I’m using the NXP FRDM-K64F board in several projects.One issue I have faced several times is that the board works fine while debugging and connected and powered by a host machine, but does not startup sometimes if powered by a battery or started without a debugger attached. I have found that the EzPort on the microcontroller is causing startup issues. The EzPort is a special serial interface present on some Kinetis, ColdFire+ and ColdFire V2 devices. The issue is that if the EzPort chip select (EZP_CS) is LOW during reset of the microcontroller, it enters the special EzPort mode. The problem is that a pull-up on the EZP_CS line might not pulled up fast enough due capacitance on the line. The commance is if something is not used, disable it! So the solution is to disable the EzPort functionality. That setting is part of the FOPT (flash option register).

The documentation points out that the Figure 32-1. Multipurpose Clock Generator (MCG) block diagram in KV5xP144M240RM.pdf is incorrect, the  /2 divider is NOT included in the feedback loop. It gives the formula to compute the VCO and MCGPLLCLK clock frequency and corresponding code.

Table of Contents 1       Introduction 2       DMA to emulate ADC Flexible Scan. 2.1         System overview and flow diagram for Flexscan. 3       SDK implementation. 3.1         ADC configuration. 3.2         LPMTR configuration 3.3         DMA configuration 4       ADC Flex Scan mode with DMA Appendix A: Requirements Reference   1    Introduction This document describes how to combine ADC, DMA and a timer to implement a ADC Flexible storing data with SDK 2.2 and MCUXpresso IDE. In this configuration ADC measures will be stored into an internal memory buffer with DMA, which imply, no CPU. With this configuration MCU uses less resources, only using ADC and DMA (2 channels) and a timer to trigger conversions. This way, the MCU does not need to read the ADC result register, because the memory management will be done by DMA automatically.   To implement this application we will use SDK libraries, which includes ADC and DMA libraries. The timer used to trigger ADC conversion will be the LPTMR. MCUXpresso IDE will be used as development environment, please check Appendix A to look where you can download SDK libraries and IDE. The project will be created from scratch, regardless of this, MCUXpresso IDE and SDK libraries allows us to create a project with some headers and libraries in the project, if you have problems creating a new project in MCUXpresso please check Reference 4.   In this document we will use the FRDM-K64F which is an ultra-low-cost development platform, but this implementation could be easily migrated to any kinetis family that support second-generation eDMA module (enhanced Direct Memory Access).   This document is an update of the community doc: Using DMA to Emulate ADC Flexible Scan Mode with KSDK  which uses old SDK libraries.   2     DMA to emulate ADC Flexible Scan   Flexible scan implementation needs 2 types of data movement: ADC measures (from peripheral to internal memory) and ADC mux change (from internal memory to peripheral). Second one is needed to change ADC input channel and have the flexible implementation, first one save ADC measures in our internal memory.   DMA peripheral (for this MCU) includes up to 16 channels, for this application we will only use 2 channels, one for ADC measures and one for ADC muxing channel. It is important to remark that we will use the linking feature in these channels to implement the ADC changing channel automatically, later in this document it will be explain this feature.   2.1         System overview and flow diagram for Flexscan.   As already mentioned, this implementation will use one DMA channel to transfer data from ADC measures (ADC0_RA register in this case) to a memory buffer (named here as g_ADC0_resultBuffer), so follow figure shows this movement:     As you can see, ADC0_COCO (conversion complete) will be the one that request a transfer from ADC0_RA to resultBuffer. Once this transfer has completed, we need to change ADC channel, so when DMA channel 1 transfer finishes, it will indicate us to trigger the other data movement, in this case from internal buffer g_ADC_mux (that save our adc channels) to the ADC0_SC1A register that sets the ADC channel, so the following diagram shows this.     To do this, this application used a DMA feature that link DMA channels, channel-to-channel linking. So, when one DMA channel finished, the linked DMA channel will be triggered, in this case when DMA channel 1 has completed to move data from ADC measure register to internal memory then DMA channel 0 need to be triggered to change the ADC channel, so next conversion ADC would have selected other ADC channel.   Once that the ADC channels is changed (and the HW trigger happens), the COCO flag from ADC will trigger other DMA request in channel 0 and the process will start again. This flow process can be repeated as many channels as we have and as many samples as we want, for this example code we will measure 3 channels and have 4 samples, so the result buffer size is 3 × 4 = 12 (the real buffer size is 16, to demonstrate that only 12 data field parts are written).   The ADC works in hardware trigger mode, with the LPTMR timer working as the trigger source. This mean that even though DMA channel 0 changed the ADC input channel, conversion will not start until HW trigger (LPTMR) start the conversion, this mean that the flow of the program can be as follow.       In the example code provided, when DMA channel 0 has changed 3 times the ADC channel, DMA channel 1 major loop will happen, and when the sample X is the last sample (sample 4) of the last channel in muxbuffer, then Major loop in DMA channel 0 happens and the application ends (or it could start again). This mean that the application here can be shown as:             3     SDK implementation   Implementation of this code can be dived in three parts; LPTMR, ADC and DMA configuration.   3.1         ADC configuration       ADC configuration is a normal ADC config, with 12 single ended, Asynchronous clock source and Vref as reference voltage. Hardware trigger and DMA support are enable to trigger conversions with LPTMR and to be able to trigger a DMA request when COCO interrupt happen. In ADC channel configuration, it is enable Conversion completed interrupt and it is loaded the value of g_ADC_mux to channel number, this will be the first channel that LPTMR will trigger.   3.2         LPMTR configuration       LPMTR is a common configuration with LPTMR as time counter. Please notice that prescaler could be used and select a prescaler clock. To set LPTMR period it is used the macro USEC_TO_COUNT, which just take the value in microseconds and it calculate the number of ticks to count, using the source clock. Also at the end, LTPMR is configured to be used as HW trigger for ADC conversions in the SIM register.   3.3         DMA configuration     For DMAMUX configuration it is enable Channel 0 and 1 and it is selected the source trigger, DMA for channel 0 (it will be triggered with linking feature) and ADC COCO flag for channel 1 (trigger when the ADC conversion complete).     For DMA configuration, it is needed to create 2 tcd configuration, there are set in transferConfig_chx. First one defined is for DMA channel 1 (data from ADC measure to internal memory), and the second is for DMA channel 0 (data from internal memory to ADC_SC1 register to change ADC channel). Please noticed that these definitions are in bytes to transfer, so some of them are sizeof(uint16_t). Here is also the setup to link channel 1 to channel 0.       Finally, it is added the adjustment for TCD, so when DMA major loop finished in both, it will point to the start of the source and destination. Noticed that this is added just for internal memory address, this is because for the case of a peripheral (ADC in this case), pointer to address doesn’t change.   Then DMA channel 1 and LPTMR are started.   When DMA channels were initialized, their callbacks were also defined;     This flags are just used for this implementation and as reference, they can be removed if needed. After Major loop has finished, SDK implementation disable DMA transfers automatically, so noticed that the callback_1 for DMA channel 1 has a line commented, that if uncommented, this application will act as a ADC that load measurements in an internal Ring buffer Indefinitely.   4     ADC Flex Scan mode with DMA With a basic Print implementation of ADC results we can show the functionality of this example project.     There are obtained the following results,         Appendix A: Requirements Download page for MCUXpresso IDE: MCUXpresso IDE|NXP  Download page for SDK 2.x drivers: Welcome to MCUXpresso | MCUXpresso Config Tools  Go to Build an SDK, select your device and click on Specify Additional Configuration Settings, verify that you have selected KDS as toolchain and then Go to SDK Builder. Click in Download Now, accept Term and conditions and download SDK packet. Please check: Generating a downloadable MCUXpresso SDK v.2 package    References   Using DMA to Emulate ADC Flexible Scan Mode with KSDK  MCUXpresso IDE: Unified Eclipse IDE for NXPs ARM Cortex-M Microcontrollers | MCU on Eclipse  https://www.nxp.com/docs/en/application-note/AN4590.pdf  Creating New Projects using installed SDK Part Support, MCUXpresso_IDE_User_Guide.pdf  

On NXP website we had provide an application note " Kinetis-M Two-Phase Power Meter Reference Design" which can been found here: http://www.nxp.com/docs/en/application-note/DRM149.pdf  This is really a quite useful solution for 2-Phase Power Meter design. From the schematic, there has a LCD display. Many customer sent email to ask for the datasheet of this LCD display(GDH-1247WP). Yes agreed, it is really difficult to find it. ( Even from the google.) I am attaching the data sheet for the segment LCD here for customer to make reference.

From K61/K64/K66 reference manual/ datasheet, it is mentioned that the SDHC clock can be set up to 50MHz. But from the SDHC timing spec, SDHC output timing violate SD specification if SDHC clock is 50MHz, because output delay (SD6 tOD) is max 6.5ns.  SD specification require setup time at SD card 6ns, then output delay should less than 4 ns if SDHC clock is 50MHz. In other word, according to the SD card specification, input set-up time is minimum 6ns, then maximum of SD6 should be 4ns in order to support 50 MHz clock frequency. So we recommend customer to drop the SDHC clock frequency to 40MHz, then the 6.5ns output valid time will allow them to meet the 6ns setup requirement for the card.

KL17 reference manual V4.1 and V5.1 with updated Figure 13-2. Kinetis Bootloader Start-up Flowchart at page 179 There with modification to add "is direct boot valid" check. Please check below picture for the detailed info: The "is direct boot valid" check function is not supported for KL17 product, the correct flow chart should be below: The "is direct boot valid" check function is reserved for further parts(such as KL82), which has one bit in BCA filed to control running code in QSPI Flash or internal Flash: Thank you for the attention.

1 Abstract      LIN (Local Interconnect Network) is a concept for low cost automotive networks, which complements the existing portfolio of automotive multiplex networks. LIN is based on the UART/SCT protocol. It can be used in the area of automotive, home appliance, office equipment, etc. The UART module in NXP kinetis L series contains the LIN slave function, it can be used as the LIN slave device in the LIN bus. Because there is few LIN slave KL sample code for the customer’s reference in our website, now this document mainly take KL43 as an example, explain how to use the FRDM-KL43 board as the LIN slave node to communicate with the LIN master device. LIN master use the specific LIN module: PCAN-USB Pro FD. Master send the publisher ID and subscriber ID, slave give the according LIN data response. This document will share the according code, hardware connection and the test result. 2 LIN bus basic knowledge review         For the convenient to understand the LIN bus, this chapter simply describe the basic knowledge for LIN bus. Mainly about the LIN topology and the LIN frame. 2.1 LIN bus topology structure       LIN bus just use the simple low cost single-wire, it uses single master to communicate with multiple slaves. The bus voltage is 12V, the speed can up to 20 kbit/s. LIN network can connect 16 nodes, but in the practical usage, normally use below 12 nodes. Figure 2-1. LIN bus topology 2.2 LIN bus frame structure          LIN Frame consists of a header (provided by the master task) and a response (provided by a slave task).     Master send publisher frame: Master send header+ data +checksum; slave just receive.     Master send subscriber frame: Master send header; slave receive send data +checksum.     The following figure is the structure of a LIN frame: Figure 2-2. LIN frame structure      LIN frame is constructed of one Break field, sync byte field (0X55), PID, data and checksum. 2.2.1 Break filed and break delimiter Break filed is consist of break and break delimiter. Break should at least 13 nominal bit times of dominant value (low voltage). The break delimiter shall be at least one nominal bit time long (high voltage). Figure 2-3. break field 2.2.2 Sync byte field Sync is a byte field with the data value 0X55. The byte field is the standard UART protocol. Figure 2-4. The sync byte field 2.2.3 Protected identifier field A protected identifier field consists of two sub-fields: the frame identifier and the parity. Bits 0 to 5 are the frame identifier and bits 6 and 7 are the parity.     ID value range: 0x00-0x3f, 64 IDs in total. It determine the frame categories and direction. Figure 2-5. The sync byte field P0 = ID0 xor ID1 xor ID2 xor ID4 P1 = -(ID1 xor ID3 xor ID4 xor ID5) -is NOT。  ID can be split in three categories:   Frame categories Frame ID Signal carrying frame Unconditional frame 0x00-0x3B Event triggered frame Sporadic frame Diagnostic frame Master request frame 0x3c Slave response frame 0x3d Reserved frame   0x3e,0x3f     2.2.4 DATA       A frame carries between one and eight bytes of data. The number of data contained in a frame with a specific frame identifier shall be agreed by the publisher and all subscribers.      For data entities longer than one byte, the entity LSB is contained in the byte sent first and the entity MSB in the byte sent last (little-endian). The data fields are labeled data 1, data 2,... up to maximum data 8. 2.2.5 checksum  The checksum contains the inverted eight bits sum with carry over all data bytes or all data bytes and the protected identifier.        Classic checksum: Checksum calculation over the data bytes. Enhanced checksum: Checksum calculation over the data bytes and the protected identifier byte.  Method: eight bits sum with carry is equivalent to sum all values and subtract 255 every time the sum is greater or equal to 256, at last, the sum data do bitwise invert.  In the receive side, do the same sum, but at last, don’t do invert, then add the received checksum data, if the result is 0XFF, it is correct, otherwise, it is wrong. 3 KL43 LIN slave example    This chapter use KL43 as the LIN slave, and communicate with the specific LIN master device, realize the LIN data sending and receiving. 3.1 Hardware prepare Hardware: FRDM-KL43，TRK-KEA8，PCAN-USB Pro FD       LIN bus voltage is 12V, but the FRDM-KL43 don’t have the LIN transceiver, so we need the external LIN transceiver connect the KL43 uart, to realize the LIN voltage switch. Here we use the TRK-KEA8 on board LIN transceiver MC33662LEF for the KL43. The MC33662LEF circuit is like this:    Figure 3-1. LIN transceiver schematic 3.1.1 FRDM-KL43 and TRK-KEA8 connections      FRDM-KL43 need to connect the UART port to the LIN transceiver. The connection shows in this table: No. FRDM-KL43 TRK-KEA8 note 1 J1-2 J10-5 UART0_RX 2 J1-4 J10-6 UART0_TX 3 J3-14 J14-1 GND 3.1.2 TRK-KEA8 and LIN master connections         LIN bus is using the signal wire.  TRK-KEA8 J14_4 is the LIN wire, it should connect with the LIN wire in PCAN-USB Pro FD. GND also need to connect together.        TRK-KEA8 P1 need a 12V DC supplier. Master also need 12V DC supplier. 3.1.3 Object connection picture   Figure 3-2. Object connections 3.2 Software flow chart and code      Now describe how to realize the LIN master and the LIN slave data transfer. LIN master send a publisher frame, the slave will receive the according data. LIN master send a subscriber frame, the slave will send the data to the master. The code is based on the KSDK2.2_FRDM-KL43 lpuart, add the LIN operation code.  3.2.1 Software flow chart         Figure 3-3. Software flow chart   3.2.2 software code     Code is based on KSDK2.2_FRDM-KL43 lpuart project, add the LIN operation code, the added code is list as follows: void LPUART0_IRQHandler(void) {      if(LPUART0->STAT & LPUART_STAT_LBKDIF_MASK)      {        LPUART0->STAT |= LPUART_STAT_LBKDIF_MASK;// clear the bit        Lin_BKflag = 1;        cnt = 0;        state = RECV_SYN;        DisableLinBreak;          }     if(LPUART0->STAT & LPUART_STAT_RDRF_MASK)      {                  rxbuff[cnt] = (uint8_t)((LPUART0->DATA) & 0xff);                  switch(state)          {             case RECV_SYN:                           if(0x55 == rxbuff[cnt])                           {                               state = RECV_PID;                           }                           else                           {                               state = IDLE;                               DisableLinBreak;                           }                           break;             case RECV_PID:                           if(0xAD == rxbuff[cnt])                           {                               state = RECV_DATA;                           }                           else if(0XEC == rxbuff[cnt])                           {                               state = SEND_DATA;                           }                           else                           {                               state = IDLE;                               DisableLinBreak;                           }                           break;             case RECV_DATA:                           recdatacnt++;                           if(recdatacnt >= 4) // 3 Bytes data + 1 Bytes checksum                           {                               recdatacnt=0;                               state = RECV_SYN;                               EnableLinBreak;                           }                           break;          default:break;                                    }                  cnt++;      }     } void uart_LIN_break(void) {     LPUART0->CTRL &= ~(LPUART_CTRL_TE_MASK | LPUART_CTRL_RE_MASK);   //Disable UART0 first     LPUART0->STAT |= LPUART_STAT_BRK13_MASK; //13 bit times LPUART0->STAT |= LPUART_STAT_LBKDE_MASK;//LIN break detection enable LPUART0->BAUD |= LPUART_BAUD_LBKDIE_MASK;         LPUART0->CTRL |= (LPUART_CTRL_TE_MASK | LPUART_CTRL_RE_MASK);     LPUART0->CTRL |= LPUART_CTRL_RIE_MASK;     EnableIRQ(LPUART0_IRQn);    } int main(void) {     uint8_t ch;     lpuart_config_t config;     BOARD_InitPins();     BOARD_BootClockRUN();     CLOCK_SetLpuart0Clock(0x1U);     LPUART_GetDefaultConfig(&config);     config.baudRate_Bps = BOARD_DEBUG_UART_BAUDRATE;     config.enableTx = true;     config.enableRx = true;     LPUART_Init(DEMO_LPUART, &config, DEMO_LPUART_CLK_FREQ);     uart_LIN_break();     while (1)     {        if(state == SEND_DATA)        {           while((LPUART0->STAT & LPUART_STAT_TDRE_MASK) == 0); // hex mode                   LPUART0->DATA = 0X01;           while((LPUART0->STAT & LPUART_STAT_TDRE_MASK) == 0); // hex mode                   LPUART0->DATA = 0X02;           while((LPUART0->STAT & LPUART_STAT_TDRE_MASK) == 0); // hex mode                   LPUART0->DATA = 0X10;//Checksum   0X10 correct, 0xaa is wrong           recdatacnt=0;           state = RECV_SYN;           EnableLinBreak;        }     } }     4 KL43 LIN slave test result   Master defines two frames: Unconditional ID Protected ID Direction Data checksum 0X2C 0XEC subscriber 0x01,0x02 0x10 0X2D 0XAD Publisher 0x01,0x02,0x03 0x4c    Now, master send 0X2C and 0X2D data, give the test result and the according waveform. 4.1 LIN master configuration Uart baud rate is: 9600bps 4.2  Send ID 0X2C and 0X2D frame       From the PC software of LIN master, we can find 0X2D ID can send the data successfully, and 0X2C ID can receive the correct data (0x01, 0x02) and checksum (0x10) from the KL43 LIN slave side. 4.2.1 0X2D ID frame oscilloscope waveform and debug result      From the debug result, we can find the buff can receive the correct ID, data and checksum from the LIN master.    4.2.2 0X2C ID frame oscilloscope waveform 4.2.3 0X2C ID SLAVE send back the wrong checksum     From the PC software, we can find if the KL43 code modify the checksum to the wrong data 0XAA, then the PC software will display the checksum error. This is the according oscilloscope waveform for the wrong checksum data. From all the above test result. We can find, KL43 as the LIN slave, it can receive the correct data from the LIN master, and when LIN master send the subscriber ID, kl43 also can send back the correct LIN data to the master. More detail, please check the attached code project. BTW, LIN spec can be downloaded from this link: http://www.cs-group.de/wp-content/uploads/2016/11/LIN_Specification_Package_2.2A.pdf   Attached is the code and the pdf version of this document:                  

Hey there Kinetis lovers!  We in the Systems Engineering team for Kinetis Microcontrollers see all kinds of situations that customers get into, and none can be particularly troubling like how the reset pin is handled.  The purpose of this document is to provide a list of Frequency Asked Questions (FAQ) that we get here in the Kinetis Systems Engineering department.  This is intended to be a living list and as such, may in no way be complete.  However we hope that you will find the below questions and answers useful.   Q:  Do I need to connect the reset signal to be able to debug a Kinetis device?   This is a commonly asked question. Strictly speaking, you do not need to connect the device reset line of a Kinetis device to the debug connector to be able to debug. The debug port MDM-AP register allows the processor to be held in reset by means of setting the System Reset Request bit using just the SWD_CLK and SWD_DIO lines.   However, before deciding to omit the reset line from your debug connector you should give some careful thought to how this may impact the ability to program and debug the device in certain scenarios. Does the debugger/flash programmer or external debug pod require the reset pin? It may be that the specific tool you are using only supports resetting the device by means of the reset line and does not offer the ability to reset the device by means of the MDM-AP. Have you changed the default function of the debug signals? You may need to use the SWD_CLK and/or the SWD_DIO signals for some other function in your application. This is especially true in low pin count packages. Once the function is changed (by means of the PORTx_PCRy registers) you will no longer have access to the MDM-AP via those signals. If you do not have access to the reset signal then you have no way of preventing the core from executing the code that will disable the SWD function of the pins. So you will not be able to re-program the device. In order to prevent this type of situation you need to either: Setup your code to change the function of the SWD pins several seconds after reset is released so that the debugger can halt the core before this happens. Put some kind of “backdoor” mechanism in your code that does not re-program the SWD function, or re-enables the SWD function, on these pins. For example, a specific character sequence sent via a UART or SPI interface.   Some Kinetis devices allow the reset function of the reset pin to be disabled. In this case you can only use the SWD signals as a means of resetting the device via the MDM-AP. If you change the SWD pin function in addition to disabling the reset pin then you must provide a backdoor means of re-enabling the SWD function if you want to be able to reprogram the device.

Overview The Sub-GHz Remote Control Dimmer is a reference design which demonstrates the functionality of the MKW01Z128 MCU working in a custom IEEE 802.15.4 star network.   This reference design is focused on a home automation application where the user is able to control various RGB bulbs connected into a network using the KW01-RCD-RD board as a remote control. Controlled devices are USB-KW019032 boards, and each board simulates an RGB bulb in a GUI.   Sub-GHz technology has some advantages over other wireless technologies such less data traffic in its respective ISM band.   Features: Documentation: Quick start guide Application users guide Board users guide Software user guide Schematics, Software, GUI and BSP: Link Best regards, Luis Burgos.

Background： NXP SC18IS602B I2C bus to SPI bridge chip is using TSSOP16 package, which is 16 leads; 0.65 mm pitch; 5 mm x 4.4 mm x 1.1 mm body. Customer requires to use a smaller package to emulate the SC18IS602B function. Kinetis L series MKL03Z16VFK4R product uses QFN24 package with 4 mm x 4 mm x 0.58 mm body. Demo Overview The I2C to SPI Bridge demo provides a replacement solution demo of SC18IS602B chip. The demo is based on FRDM-KL03Z board using I2C0 module as I2C slave and SPI0 module as SPI master. Provided data buffer size is 400bytes. The demo software is based on KSDK V2.0 for FRDM-KL03Z software. I2C slave interface: Pin number                 Function              FRDM-KL03Z jumper PTB3                          I2C0_SCL           J2-10 PTB4                          I2C0_SDA           J2-9   SPI master interface: Pin number                 Function              FRDM-KL03Z jumper PTA5                           SPI0_SS             J2_3 PTA6                           SPI0_MISO         J2_5 PTA7                           SPI0_MOSI         J2_4 PTB0                           SPI0_SCK           J2_6   INT pin (indicates if I2C to SPI Bridge allows i2c master start a new i2c transfer, low is active) Pin number                 Function              FRDM-KL03Z jumper PTB11                        GPIO output         J2_2   Connect I2C master with FRDM-KL03Z I2C slave interface and connect SPI slave with FRDM-KL03Z SPI master interface; Connect FRDM-KL03Z GND to I2C master and SPI slave before add power to those boards.  Below is the hardware platform connection way: I2C to SPI Bridge Demo Function For the KL03 chip with one SPI0_PCS0 chip select pin, I2C to SPI Bridge demo only supports function ID 0x01 as SPI write command. For example: if i2c master want to write 8bytes (0x21,0x22...0x28) to SPI slave, the i2c master needs to send below data to FRDM-KL03Z board:   [START] + [I2C Slave address+/W] + [0x01](Function ID) + [0x21](data 1) + [0x22](data 2) + ... +[0x28](data 😎 + [STOP]     I2C to SPI bridge demo supports Function ID 0xF0 to configure SPI interface: There provides four SPI baud rate: 6Mbps/3Mbps/1.5Mbps/1Mbps. More detailed info, please check below picture (picture abstracted from SC18IS602B datasheet): For example: customer could configure SPI baud rate to 3Mbps with send below data to FRDM-KL03Z board:        [START] + [I2C Slave address+/W] + [0Xf0](Function ID) + [0x01](data 1) + [STOP] Hardware Platform The demo is based on FRDM-KL03Z board, using internal IRC48M clock as system and bus clock source. There doesn’t need external clock source. Toolchain supported - IAR embedded Workbench 7.60.1  (Tested) - Keil MDK 5.18a - GCC ARM Embedded 2015-4.9-q3 - Kinetis Development Studio IDE 3.2.0 Running the Demo Connect a USB cable between the host PC and the USB port on the target board. Open a serial terminal with the following settings:     - 9600 baud rate     - 8 data bits     - No parity     - One stop bit     - No flow control Download the program to the target board. I2C master start to configure SPI interface      I2C to SPI bridge board I2C address is 0x7E. I2C master write data to SPI slave    I2C master write 10bytes to SPI slave, it will send 11bytes (includes one function ID 0x01). The first data is 0xAA and the last data is 0x22.    After I2C to SPI Bridge receive the data, it will send 10bytes to SPI slave.        I2C to SPI Bridge receive 10 bytes     I2C to SPI Bridge send 10bytes to SPI slave I2C master read data from SPI slave    I2C master read 10bytes(0x10 to 0x19) from SPI slave need to write data to SPI slave at first, then read data from I2C to SPI bridge data buffer directly.    Here just shows read 10bytes from I2C to SPI bridge data buffer. Attached I2C to SPI Bridge demo software default location is: ..\SDK_2.0_FRDM-KL03Z\boards\frdmkl03z\user_apps\i2c_to_spi

USB secondary ISP bootloader for LPC11U68  Overview        A Secondary Bootloader (SBL) is a piece of code that allows a user application code to be downloaded using alternative channels other than the standard UART0 used by the internal bootloader (on chip). Possible secondary bootloaders can be written for USB, Ethernet, SPI, SSP, CAN, and even I/Os. The secondary bootloader utilizes IAP as a method to update the user’s application code.        The internal bootloader is the firmware that resides in the microcontroller’s boot ROM block and is executed on power-up and resets. After the boot ROM’s execution, the secondary bootloader would be executed, which will then execute the user application.      The purpose of this document is to use USB as an example for developing the secondary bootloader and the code was tested using the LPCXpresso 11U68 evaluation board.       The MSCD presents easy integration with a PC‘s operating systems. This class allows the embedded system’s flash memory space be represented as a folder in Windows/Linux. The user can update the flash with the binary image using drag and drop, so the following sections will present a guideline for development and implementation of the USB secondary bootloader design, configuration, and test.      USB secondary bootloader code is base on the USB Mass Storage Class demo. However in this application note, we do not attempt to explain how the Mass Storage Class is implemented. Fig 1 LPCXpresso Board for LPC11U68 Setup file (sbl_config.h)       This file configures the secondary bootloader. The user should change this according to their application.       Some definitions and explanation: MAX_USER_SECTOR – This parameter is device dependent. In a 256 KB device, it will be 29 sectors, however the size of the last 5 sectors become the 32 KB instead of the 4 KB, so in the application, MAX_USER_SECTOR chooses 23 (Fig 2). CRP – Code Read Protection. This parameter allows select the desired CRP level. Choosing CRP3, the primary bootloader’s entry mechanism check will be bypassed. Fig 3 for CRP details. Fig 2 Flash sectors in LPC11U68 Fig 3 Code Read Protection (CRP) Secondary bootloader entry        The boot sequence shown below is used when entering the secondary USB bootloader. Fig 4 Using an entry pin      The secondary USB bootloader will check the status of a GPIO pin to determine if it should enter into programming mode. This is the easiest way since no post processing is needed. And this secondary bootloader uses P0.16. Automatic secondary bootloader entry       If the secondary USB bootloader detects that no user application is present upon reset, it will automatically enter programming mode. ISP entry disabled     If the secondary USB bootloader detects that a user application has already been installed and that CRP is set to level 3, then it will not enter ISP mode. Bootloader size        Since the bootloader resides within user programmable flash, it should be designed as small as possible. The larger the secondary USB bootloader is the less flash space is available to the user application. By default, the USB bootloader has been designed to fit within the first two flash sectors (Sector 0-1) so that the user application can start from sector 2. Code placement in flash       The secondary bootloader is placed at the starting address 0x0 so that it will be executed by the LPC11U68 after reset. Flash programming is based on a sector-by-sector basis. This means that the code for the user application should not be stored in any of the same flash sectors as the secondary bootloader and for efficient use of the flash space, the user application should be flashed into the next available empty sector after the bootloader.        In the application, the start sector is 3 (0x0000_3000) which is used to store the user application code. User application execution        If the SW2 button is not depressed, the secondary bootloader will start the execution of the user application. Execution of the user application is performed by updating the stack pointer (SP) and program counter (PC) registers. The SP points to the new location where the user application has allocated the top of its stack .The PC on the other hand contains the location of the first executable instruction in the user application. From here on the CPU will continue normal execution and initializations specified on the user application. By default, the bootloader uses 2 flash sectors. Therefore, to utilize the remaining flash, the secondary bootloader will look for the user application at 0x00003000 Handing interrupts      The LPC11U68 contains a NVIC (Nested Vectored Interrupt Controller) that handles all interrupts. When an interrupt occurs the processor uses the vector table to locate the address of the handler.      On the LPC11U68 the vector table is located in the same area of flash memory as the secondary bootloader. The secondary bootloader is designed to be permanently resident in flash memory and therefore it is not possible to update the contents of the vector table every time a new application is downloaded.       The Cortex-M3 core allows the vector table to be remapped; however this is not the case with the Cortex-M0. Because of this, the secondary bootloader has been designed to redirect the processor to the handler listed in a vector table located in the application area of flash memory, see Fig 5. Fig 5 User application       To execute the user application the secondary USB bootloader will load the new SP and PC values into their respective registers, allowing the CPU to execute the new code correctly. Therefore, the user application must be built so that it can run from that starting address. In the application, this address is 0x00003E00. So relocate the user application storage area by following corresponding IDE’s User Guide.  Testing  Creating the binary file             In this application, I build the demos_switch_blinky which is from the LPCOpen library to create the binary which is compatible with the secondary USB bootloader. The binary see Table 1. 08 04 00 10 B5 09 00 00 07 07 00 00 9B 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A1 E1 FF EF 00 00 00 00 00 00 00 00 00 00 00 00 A7 09 00 00 00 00 00 00 00 00 00 00 E5 09 00 00 27 03 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 01 03 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E1 09 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 38 B5 63 4C 25 68 28 07 07 D5 96 20 E0 60 61 48 00 78 00 28 01 D1 00 F0 F7 F8 20 68 0C 21 29 40 01 43 21 60 31 BD 38 B5 5A 4C A0 78 40 1C A0 70 C0 B2 65 28 34 DB 00 25 A5 70 20 78 00 28 2F D0 60 78 00 28 03 D0 02 28 16 D0 0A D3 20 E0 01 21 00 F0 CA F8 00 21 01 20 00 F0 C6 F8 00 21 02 20 13 E0 01 21 01 20 00 F0 BF F8 00 21 00 20 00 F0 BB F8 00 21 02 20 08 E0 01 21 00 F0 B5 F8 00 21 01 20 00 F0 B1 F8 00 21 01 20 00 F0 AD F8 00 E0 65 70 60 78 40 1C 60 70 C0 B2 03 28 00 DB 65 70 31 BD F8 B5 00 F0 36 F9 00 F0 C2 F8 3A 48 01 68 02 22 91 43 01 60 01 68 38 4A 0A 40 02 60 35 4F 01 20 38 70 36 48 00 68 0A 21 00 F0 2B F9 1E 21 00 F0 28 F9 40 1E 00 26 80 21 49 04 88 42 0C D2 30 49 48 60 30 48 02 68 12 02 12 0A C0 23 1B 06 13 43 03 60 8E 60 07 20 08 60 01 20 2B 49 08 60 23 4C 20 00 00 F0 18 F9 29 48 01 68 80 22 12 03 0A 43 02 60 20 68 01 21 01 43 21 60 20 68 01 21 88 43 20 60 20 68 80 21 88 43 20 60 A6 60 FA 20 80 00 60 60 20 68 40 21 01 43 21 60 20 68 80 21 01 43 21 60 20 68 80 20 80 04 1A 49 08 60 20 68 30 21 01 43 21 60 18 4D 28 78 00 28 12 D1 38 78 00 28 0E D0 00 21 00 20 00 F0 3E F8 00 21 01 20 00 F0 3A F8 00 21 02 20 00 F0 36 F8 FA 20 80 00 E0 60 3E 70 E8 7B 00 28 E6 D1 01 20 38 70 E3 E7 00 40 02 40 04 00 00 10 00 20 00 A0 FF FF FE FF 00 00 00 10 10 E0 00 E0 20 ED 00 E0 1C 80 04 40 14 82 04 40 00 E1 00 E0 01 00 00 A0 49 01 40 18 83 54 70 47 10 B5 32 4C 20 00 00 F0 BF F8 E1 21 49 02 20 00 00 F0 C7 F8 03 20 E0 60 81 20 A0 60 80 20 20 63 10 BD 00 00 03 28 00 DB 70 47 80 B5 01 23 4B 40 2D A1 0A 5C 2B A1 09 5C A0 20 00 06 FF F7 DC FF 01 BD 00 00 03 28 00 DB 70 47 10 B5 A0 21 09 06 24 A2 12 5C 92 00 89 18 8C 22 92 01 01 23 00 BF 21 A4 20 5C 83 40 8B 50 10 BD 00 00 F8 B5 FF F7 C7 FF A0 25 2D 06 28 00 00 F0 B6 F8 00 24 00 BF 18 A6 31 5D 88 00 28 18 80 22 92 01 80 18 00 BF 15 A2 12 5D 03 68 01 27 97 40 1F 43 07 60 01 23 28 00 FF F7 A9 FF 64 1C 03 2C EA DB F1 BD 00 00 80 B5 07 48 01 68 80 22 52 02 0A 43 02 60 19 22 0A A1 04 48 00 F0 98 F8 01 BD 00 00 00 80 00 40 80 80 04 40 00 40 04 40 80 B5 FF F7 E9 FF 00 F0 B1 F8 01 BD 02 02 02 00 11 10 12 00 00 03 81 00 00 04 81 00 00 05 81 00 00 08 81 00 00 09 81 00 00 0B 02 00 00 0C 02 00 00 0D 02 00 00 0E 02 00 00 12 81 00 00 13 81 00 00 17 01 00 01 09 01 00 01 0B 81 00 01 0E 81 00 01 14 82 00 01 15 82 00 01 16 81 00 01 17 82 00 01 1A 81 00 01 1B 81 00 01 1D 81 00 02 00 01 00 02 01 01 00 02 03 82 00 80 B5 00 F0 EF F8 01 49 08 60 01 BD 00 00 00 10 80 B5 03 4A 12 68 12 69 52 68 90 47 02 BD 00 00 F8 1F FF 1F 03 48 01 68 80 22 D2 05 0A 43 02 60 70 47 00 00 80 80 04 40 15 49 01 22 8A 61 0A 68 80 23 5B 01 13 43 0B 60 07 21 81 60 10 21 81 62 70 47 70 B5 04 00 0D 00 01 20 0E 49 08 60 00 F0 8F F8 06 00 29 01 FF F7 D3 FF 01 00 E0 68 80 22 02 43 E2 60 C8 B2 20 60 08 04 00 0E 60 60 E0 68 80 22 90 43 E0 60 30 00 FF F7 C2 FF 70 BD 00 00 80 80 04 40 98 80 04 40 02 48 01 68 40 22 0A 43 02 60 70 47 80 80 04 40 00 2A 00 D1 70 47 30 B4 0C 68 23 0C 25 0A E4 B2 00 2C 12 D0 02 2C 01 D0 0A D3 11 E0 ED B2 AC 00 04 19 02 2D 01 DB F4 25 00 E0 F0 25 63 51 07 E0 2D 06 AC 0D 04 19 23 66 02 E0 2D 06 AC 0D 03 51 09 1D 52 1E E0 D1 30 BC 70 47 FE E7 38 B5 20 20 00 F0 E8 F8 00 20 00 90 11 48 02 E0 00 99 49 1C 00 91 00 99 81 42 F9 DB 01 20 00 F0 1F F8 0D 48 01 68 01 24 03 22 91 43 21 43 01 60 80 20 00 F0 C7 F8 09 4D 23 20 28 60 80 20 00 F0 CB F8 68 68 C0 07 FC D5 2C 67 03 20 00 F0 10 F8 31 BD 00 00 C4 09 00 00 10 C0 03 40 08 80 04 40 42 49 FF E7 08 60 00 20 48 60 01 20 48 60 70 47 3F 49 F7 E7 43 A0 CA 05 12 0F 92 00 80 58 C9 06 C9 0E 49 1C 49 00 FF F7 49 FF 00 BD 00 B5 00 20 3B 49 03 22 8B 6E 13 40 11 D0 02 2B 11 D0 02 D3 03 2B 10 D0 00 BD 89 6B 0A 40 08 D0 01 2A 03 D0 03 2A 1A D1 31 48 00 E0 2F 48 00 68 00 BD 2D 48 00 BD C9 69 D6 E7 8B 6B 1A 40 08 D0 01 2A 03 D0 03 2A 05 D1 29 48 00 E0 27 48 00 68 00 E0 25 48 09 68 C9 06 C9 0E 49 1C 48 43 00 BD 00 00 00 00 10 B5 00 20 22 4C 03 21 A2 6E 0A 40 30 D0 02 2A 15 D0 21 D3 03 2A 2C D1 A2 6B 11 40 08 D0 01 29 03 D0 03 29 05 D1 19 48 00 E0 17 48 00 68 00 E0 14 48 21 68 C9 06 C9 0E 49 1C 48 43 19 E0 E1 69 14 A0 CA 05 12 0F 92 00 80 58 C9 06 C9 0E 49 1C 49 00 FF F7 EB FE 0C E0 A2 6B 11 40 08 D0 01 29 03 D0 03 29 05 D1 09 48 00 E0 07 48 00 68 00 E0 04 48 21 6F FF F7 DA FE 10 BD 00 00 40 80 04 40 70 80 04 40 00 1B B7 00 D0 09 00 00 D4 09 00 00 08 80 04 40 00 00 00 00 C0 27 09 00 90 05 10 00 C0 5C 15 00 F0 B3 1A 00 20 0B 20 00 00 9F 24 00 E0 32 29 00 C0 C6 2D 00 50 97 31 00 E0 67 35 00 70 38 39 00 00 09 3D 00 40 16 40 00 80 23 43 00 C0 30 46 00 0B 49 0A 68 10 43 09 4A 02 40 C8 20 00 02 10 43 08 60 70 47 06 49 0A 68 82 43 04 48 10 40 C8 22 12 02 02 43 0A 60 70 47 00 00 00 00 FF 25 00 00 38 82 04 40 70 B4 01 21 00 22 13 E0 04 68 00 1D 0C 42 02 D0 4D 46 6D 1E 64 19 22 60 24 1D 1B 1F 04 2B FA D2 25 00 9E 07 01 D5 22 80 AD 1C 0B 40 00 D0 2A 70 03 68 00 1D 00 2B E7 D1 70 BC 70 47 10 B5 07 49 79 44 18 31 06 4C 7C 44 16 34 04 E0 08 1D 0A 68 89 18 88 47 01 00 A1 42 F8 D1 10 BD 08 00 00 00 14 00 00 00 9D FF FF FF 08 00 00 00 00 00 00 10 00 00 00 00 00 F0 0B F8 00 28 01 D0 FF F7 DE FF 00 20 00 BF 00 BF FF F7 0C FD 00 F0 02 F8 01 20 70 47 80 B5 00 F0 02 F8 01 BD FE E7 07 46 38 46 00 F0 02 F8 FB E7 FE E7 20 21 09 03 26 31 18 20 AB BE F9 E7 01 48 80 47 01 48 00 47 D9 09 00 00 C5 09 00 00 00 BF 00 BF 00 BF 00 BF FF F7 D2 FF 00 1B B7 00 00 80 00 00 80 B5 FF F7 DF FD 01 BD FE E7 FE E7 FE E7                                                    Table 1 Drag and drop the binary file Running the secondary bootloader, and connect a USB cable between the PC and the J3, see Fig 6; Fig 6 Drag and drop the binary file to the driver, see Fig 7;    Fig 7 Review the values of the user application in the relative area , see Fig 8; Fig 8

Download Kinetis M bare-metal drivers and software examples installation file. Changes in 4.1.6 : Modified FreeRTOS kernel to disable all interrupts prior entry to critical section and enable all interrupts upon exiting from critical section. This kernel behavior is compatible with standard FreeRTOS port to the ARM Cortex-M0 core. All freertos_cfg header files updated to reflect kernel change. Updated PLL_Disable macro and Quad Timer driver. Added UART_SetBaudRate macro. Removed RCM_ClrResetFlags macro. Fixed issue of generating callback events after conversion for these ADC channels with interrupt disabled.