Kinetis Microcontrollers Knowledge Base

cancel
Showing results for 
Search instead for 
Did you mean: 

Kinetis Microcontrollers Knowledge Base

Discussions

    以DMA方式通过UART发送数据应该是工程应用中很常用的一种方式了,尤其是在需要频繁发送数据或者数据包长度较大的场合,如果使用传统的UART查询或者中断方式发送和接收数据,对CPU资源的占用将是极大的浪费,带操作系统的应用还好些,如果是纯粹的前后台程序有时不能容忍的,所以DMA方式是很恰当的选择。 而本篇以Kinetis L系列为例介绍一下以DMA方式通过UART端口发送长数据包,当然不同于K系列复杂强大的eDMA功能,L系列的DMA模块配置起来还是比较简单的。 测试平台:IAR6.7 + KL26 FRDM 测试代码:FRDM-KL26Z_SC\FRDM-KL26Z_SC_Rev_1.0\klxx-sc-baremetal\build\iar\uart0_dma        其实KL26的官方sample code中是自带uart0_dma例程的,但是实现的功能只是将UART口接收到的每一个字节的数据通过DMA方式再发送出去(即环形缓冲),这样用来作为一个功能演示的demo是可以,但是往往我们需要的是将某缓冲区的数据以DMA方式发送出去或者将接收到的数据以DMA方式写到某缓冲区这样的功能,为此我们就需要在原有的例程上进行修改从而达到我们的应用目的,这里给出几点需要修改的地方,并做了相关注释(整个工程见最后附件): 1)定义待发送缓冲区: /* array to be sended */ uint8 testdata[]={"\nFreescale Kinetis KL26\n"}; 2)设置DMA源地址: #define DMA0_DESTINATION  0x4006A007    /* the memory adress of UART0_D register */ #define DMA0_SOURCE_ADDR  (uint32)testdata    /* define the source data array address */ 3) 在DMA0_init()函数中修改发送数据包的长度: DMA_SAR0 = DMA0_SOURCE_ADDR;    //Set source address to UART0_D REG DMA_DSR_BCR0 = DMA_DSR_BCR_BCR(sizeof(testdata));    //Set BCR to know how many bytes to transfer DMA_DCR0 &= ~(DMA_DCR_SSIZE_MASK | DMA_DCR_DSIZE_MASK);    //Clear source size and destination size fields 4)添加源地址自动加1功能,因为之前的环形缓冲方式只是单字节数据,所以不需要源地址递增,但是由于我们这次需要发送整个数据包,所以这里我们就需要将源地址递增功能打开,而具体递增1,2还是4则取决于发送数据的最小单位(8bit,16bit or 32bit): /* Set DMA as follows: Source size is 8-bit size Destination size is 8-bit size Cycle steal mode External requests are enabled source address increments 1 automatically */ DMA_DCR0 |= (DMA_DCR_SSIZE(1) | DMA_DCR_DSIZE(1) | DMA_DCR_CS_MASK | DMA_DCR_ERQ_MASK | DMA_DCR_EINT_MASK | DMA_DCR_SINC_MASK ); 5)配置DMAMUX通道为UART0 TX即发送通道(通道号为3),因为我们需要的是UART0_TX触发DMA传送: DMA_DAR0 = DMA0_DESTINATION;    //Set source address to UART0_D REG DMAMUX0_CHCFG0 = DMAMUX_CHCFG_SOURCE(3);    //Select UART0 TX as channel source DMAMUX0_CHCFG0 |= DMAMUX_CHCFG_ENBL_MASK;    //Enable the DMA MUX channel 6)在UART0_DMA_init()函数中修改UART0发送缓冲区为空时即触发DMA发送: void UART0_DMA_init(void) { UART0_C2 &= ~(UART0_C2_TE_MASK | UART0_C2_RE_MASK);  //Disable UART0 UART0_C5 |= UART0_C5_TDMAE_MASK;                      // Turn on DMA request(Transmit) for UART0 UART0_C2 |= (UART0_C2_TE_MASK | UART0_C2_RE_MASK);  //Enable UART0 } 7)在DMA发送完成中断服务函数中禁掉DMA通道,实现单次发送,即每个数据包发送完成之后即停止发送,否则不禁掉的话会一直触发DMA发送,造成串口堵塞: void DMA0_IRQHandler(void) {  /* Create pointer & variable for reading DMA_DSR register */ volatile uint32_t* dma_dsr_bcr0_reg = &DMA_DSR_BCR0; uint32_t dma_dsr_bcr0_val = *dma_dsr_bcr0_reg; if (((dma_dsr_bcr0_val & DMA_DSR_BCR_DONE_MASK) == DMA_DSR_BCR_DONE_MASK)      | ((dma_dsr_bcr0_val & DMA_DSR_BCR_BES_MASK) == DMA_DSR_BCR_BES_MASK)      | ((dma_dsr_bcr0_val & DMA_DSR_BCR_BED_MASK) == DMA_DSR_BCR_BED_MASK)      | ((dma_dsr_bcr0_val & DMA_DSR_BCR_CE_MASK) == DMA_DSR_BCR_CE_MASK)) { DMA_DSR_BCR0 |= DMA_DSR_BCR_DONE_MASK;                //Clear Done bit DMA_DSR_BCR0 = DMA_DSR_BCR_BCR(sizeof(testdata));      //Reset BCR dma0_done = 1; } /* once the array complete the transfer, then disable the DMA channel.*/ DMAMUX0_CHCFG0 &= ~DMAMUX_CHCFG_ENBL_MASK; }        将上述代码做完相应修改即可实现单次将内存缓冲区数据以DMA方式通过UART0发送出去,效果如下。此外,如果想周期性触发或者条件性触发,则只需再相应位置添加“ DMAMUX0_CHCFG0 |= DMAMUX_CHCFG_ENBL_MASK; ”这句代码即可打开通道,然后立即会触发UART0_TX发送数据,然后待数据包发送完之后再次停止等待下次使能。 另外,关于DMA的传输速度的话,因为其独立占用一条自己的总线,其搬运时钟为系统时钟(即coreclock/Systemclock),相比于总线上的传输速度,本例程中整个数据包的发送时间主要是取决于UART串口的波特率*数据包长度。 附件为修改好后的完整工程:
View full article
Introduction With the growth of the Internet of Things (IoT), more and more applications are incorporating the use of sensors while also requiring power efficiency and increased performance.  A popular interface for these sensors is the I2C protocol. The I2C bus is a great protocol that is a true multi-master protocol and allows for each bus to contain many devices.  As the performance demand of the application grows, so will the speed of the I2C bus as it will be necessary to get more data from the sensors and/or at a faster rate.  Many applications may already have a need to operate an I2C bus at 400 kHz or more.  Higher data rates means the MCU core will need to spend more time servicing the I2C transactions.  The DMA module is one good way to free up the core in order to let it tend to other aspects of the application.  This can add much needed or much desired performance to applications.  Especially applications that may be using small, power efficient, single core MCUs. It may seem like an easy, straight-forward task to add I2C reads from a sensor to an application.  However I2C is a time sensitive protocol and consequently, so is the I2C peripherals on MCUs.  It is important to understand the time requirements and how to overcome them. The recommended approach is to use DMA to transfer the received I2C data to the desired buffer in your application software.  This document is going to outline how to setup your DMA and provide an example of how to do this for a KW40 device using the Kinetis SDK version 1.3.  The KW40 is being targeted because this is a small, power efficient MCU that incorporates a radio for your wireless applications and as such, it is likely that your application could need this DMA approach.  The KSDK version 1.3 is being targeted because this version of the SDK does not currently support DMA transactions for the I2C peripheral. Understanding the Kinetis I2C peripheral module Before getting into the specifics of creating a DMA enabled I2C driver, it is important to understand some basics of the Kinetis I2C peripheral module.  This module handles a lot of the low-level timing.  However the I2C registers must be serviced in a timely manner to operate correctly.  Take the case of a master reading data from a typical I2C sensor as shown in the diagram below. In the diagram above, the red lines indicate points in the transaction where software or DMA needs to interact with the I2C peripheral to ensure the transaction happens correctly.  To begin a transaction the core must change the MST bit which puts a start bit on the bus (marked by symbol ST).  Immediately following this, the core should then also write the target slave's address (Device Address) including the read/write bit (R/W).  Once this transaction is complete, the I2C will issue an interrupt and then the core should write the register address to be read from. Upon completion of that being put on the bus, the I2C will issue another interrupt and the master should then put a repeated start (SR) on the bus as well as the slave's address again.  Now the slave will send data to the master (once the master begins the transaction by issuing a dummy read of the I2C data register).  In the standard configuration, the I2C peripheral will automatically send the NAK or AK depending on the configuration of the TXAK bit in the I2C peripheral.  Because of this automation, it is important that this bit be handled properly and is configured one frame in advance. Furthermore, to ensure that the NAK bit is sent at the appropriate time, the TXAK bit must be set when the second to last byte is received.  The timing of this configuration change is very important to ensuring that the transaction happens properly. This document will describe how to use DMA to receive the data.  The DMA will be configured before the transaction begins and will be used to receive the data from the slave.  The document will also discuss options to handle proper NAK'ing of the data to end the transaction. Writing a DMA I2C master receive function The first step in adding DMA capability to your SDK driver is to create a new receive function with an appropriate name.  For this example, the newly created receive function is named I2C_DRV_MasterReceiveDataDMA.  To create this function, the I2C_DRV_MasterReceive function (which is called for both blocking and non-blocking) was copied and then modified by removing the blocking capability of the function. Then in this function, after the dummy read of the IIC data register that triggers the reception of data, the DMA enable bit of the I2C control register is written. /*FUNCTION********************************************************************** * * Function Name : I2C_DRV_MasterReceiveDataDMA * Description   : Performs a non-blocking receive transaction on the I2C bus *                 utilizing DMA to receive the data. * *END**************************************************************************/ i2c_status_t I2C_DRV_MasterReceiveDataDMA(uint32_t instance,                                                const i2c_device_t * device,                                                const uint8_t * cmdBuff,                                                uint32_t cmdSize,                                                uint8_t * rxBuff,                                                uint32_t rxSize,                                                uint32_t timeout_ms) {     assert(instance < I2C_INSTANCE_COUNT);     assert(rxBuff);       I2C_Type * base = g_i2cBase[instance];     i2c_master_state_t * master = (i2c_master_state_t *)g_i2cStatePtr[instance];             /* Return if current instance is used */     OSA_EnterCritical(kCriticalDisableInt);         if (!master->i2cIdle)     {         OSA_ExitCritical(kCriticalDisableInt);         return kStatus_I2C_Busy;     }         master->rxBuff = rxBuff;     master->rxSize = rxSize;     master->txBuff = NULL;     master->txSize = 0;     master->status = kStatus_I2C_Success;     master->i2cIdle = false;     master->isBlocking = true;     OSA_ExitCritical(kCriticalDisableInt);             while(I2C_HAL_GetStatusFlag(base, kI2CBusBusy));     I2C_DRV_MasterSetBaudRate(instance, device);         /* Set direction to send for sending of address. */     I2C_HAL_SetDirMode(base, kI2CSend);       /* Enable i2c interrupt.*/     I2C_HAL_ClearInt(base);     I2C_HAL_SetIntCmd(base, true);       /* Generate start signal. */     I2C_HAL_SendStart(base);       /* Send out slave address. */     I2C_DRV_SendAddress(instance, device, cmdBuff, cmdSize, kI2CReceive, timeout_ms);       /* Start to receive data. */     if (master->status == kStatus_I2C_Success)     {         /* Change direction to receive. */         I2C_HAL_SetDirMode(base, kI2CReceive);                 /* Send NAK if only one byte to read. */         if (rxSize == 0x1U)         {         I2C_HAL_SendNak(base);         }         else         {         I2C_HAL_SendAck(base);         }                 /* Dummy read to trigger receive of next byte in interrupt. */         I2C_HAL_ReadByte(base);                 /* Now set the DMA bit to let the DMA take over the reception. */         I2C_C1_REG(I2C1) |= I2C_C1_DMAEN_MASK;                 /* Don't wait for the transfer to finish. Exit immediately*/     }     else if (master->status == kStatus_I2C_Timeout)     {         /* Disable interrupt. */         I2C_HAL_SetIntCmd(base, false);                 if (I2C_HAL_GetStatusFlag(base, kI2CBusBusy))         {         /* Generate stop signal. */         I2C_HAL_SendStop(base);         }                 /* Indicate I2C bus is idle. */         master->i2cIdle = true;     }         return master->status; } After writing the DMA driver, a DMA specific transfer complete function must be implemented. This is needed in order for the application software to signal to the driver structures that the transfer has been completed and the bus is now idle. In addition, the DMA enable bit needs to be cleared in order for other driver functions to be able to properly use the IIC peripheral. void I2C_DRV_CompleteTransferDMA(uint32_t instance) {     assert(instance < I2C_INSTANCE_COUNT);     I2C_Type * base = g_i2cBase[instance];     i2c_master_state_t * master = (i2c_master_state_t *)g_i2cStatePtr[instance];         I2C_C1_REG(base) &= ~(I2C_C1_DMAEN_MASK | I2C_C1_TX_MASK);     I2C_C1_REG(base) &= ~I2C_C1_MST_MASK;;        /* Indicate I2C bus is idle. */     master->i2cIdle = true; } DMA Configuration Next, the application layer needs a function to configure the DMA properly, and a DMA callback is needed to properly service the DMA interrupt that will be used as well as post a semaphore. But before diving into the specifics of that, it is important to discuss the overall strategy of using the DMA in this particular application. After every transaction, the data register must be serviced to ensure that all of the necessary data is received.  One DMA channel can easily be assigned to service this activity.  After the reception of the second to last data byte, the TXAK bit must be written with a '1' to ensure that the NAK is put on the bus at the appropriate time. This is a little trickier to do.  There are three options: A second dedicated DMA channel can be linked to write the I2C_C1 register every time the I2C_D register is serviced.  This option will require a second array to hold the appropriate values to be written to the I2C_C1 register.  The following figure illustrates this process. The second DMA channel can be linked to write the I2C_C1 register after the second to last data byte has been received.  This option would require that the primary DMA channel be set to receive two data bytes less than the total number of desired data bytes.  The primary DMA channel would also need to be re-configured to receive the last two bytes (or the application software would need to handle this).  However this could be a desirable programming path for applications that are memory constrained as it reduces the amount of memory necessary for your application. The primary DMA channel can be set to receive two data bytes less than the total number of desired data bytes and the core (application software) can handle the reception of the last two bytes.  This would be a desirable option for those looking for a simpler solution but has the drawback that in a system where the core is already handling many other tasks, there may still be issues with writing the TXAK bit on time. This example will focus on option number 1, as this is the simplest, fully automatic solution.  It could also easily be modified to fit the second option as the programmer would simply need to change the number of bytes to receive by the primary DMA and add some reconfiguration information in the interrupt to service the primary DMA channel. DMA Channel #1 The first DMA channel is configured to perform 8-bit  transfers from the I2C data register (I2C_D) to the buffer to hold the desired data.  This channel should transfer the number of desired bytes minus one.  The final byte will be received by the core.  Other DMA configuration bits that are important to set are the cycle steal bit, disable request bit, peripheral request bit (ERQ), interrupt on completion of transfer (EINT), and destination increment (DINC).  It also important to configure the link channel control to perform a link to channel LCH1 after each cycle-steal transfer and LCH1 should be configured for the channel that will transfer from memory to the I2C control register (I2C_C1).  The first DMA channel is configured as shown below. // Set Source Address (this is the UART0_D register       DMA_SAR0 = (uint32_t)&I2C_D_REG(base);             // Set BCR to know how many bytes to transfer       // Need to set to desired size minus 1 because the last will be manually       // read.        DMA_DSR_BCR0 = DMA_DSR_BCR_BCR(destArraySize - 1);             // Clear Source size and Destination size fields.        DMA_DCR0 &= ~(DMA_DCR_SSIZE_MASK                     | DMA_DCR_DSIZE_MASK                     );       // Set DMA as follows:       //     Source size is byte size       //     Destination size is byte size       //     D_REQ cleared automatically by hardware       //     Destination address will be incremented after each transfer       //     Cycle Steal mode       //     External Requests are enabled       //     Interrupts are enabled       //     Asynchronous DMA requests are enabled.       //     Linking to channel LCH1 after each cycle steal transfer       //     Set LCH1 to DMA CH 1.        DMA_DCR0 |= (DMA_DCR_SSIZE(1)             // 1 = 8-bit transfers                    | DMA_DCR_DSIZE(1)           // 1 = 8-bit transfers                    | DMA_DCR_D_REQ_MASK                    | DMA_DCR_DINC_MASK                    | DMA_DCR_CS_MASK                    | DMA_DCR_ERQ_MASK                    | DMA_DCR_EINT_MASK                    | DMA_DCR_EADREQ_MASK                    | DMA_DCR_LINKCC(2)          // Link to LCH1 after each cycle-steal transfer                    | DMA_DCR_LCH1(1)            // Link to DMA CH1                    );       // Set destination address       DMA_DAR0 = (uint32_t)destArray; DMA Channel #2 The second DMA channel, which is the linked channel, should be configured to perform 8-bit transfers that transfer data from an array in memory (titled ack_nak_array in this example) to the I2C control register (I2C_C1).  This channel should also disables requests upon completion of the entire transfer, and enable the cycle-steal mode.  In this channel, the source should be incremented (as opposed to the destination as in the first channel). This channel is configured as shown below: // Set Source Address (this is the UART0_D register       DMA_SAR1 = (uint32_t)ack_nak_array;             // Set BCR to know how many bytes to transfer       // Need to set to desired size minus 1 because the last will be manually       // read.       DMA_DSR_BCR1 = DMA_DSR_BCR_BCR(destArraySize - 1);             // Clear Source size and Destination size fields.        DMA_DCR1 &= ~(DMA_DCR_SSIZE_MASK                     | DMA_DCR_DSIZE_MASK                     );             // Set DMA as follows:       //     Source size is byte size       //     Destination size is byte size       //     D_REQ cleared automatically by hardware       //     Destination address will be incremented after each transfer       //     Cycle Steal mode       //     External Requests are disabled       //     Asynchronous DMA requests are enabled.       DMA_DCR1 |= (DMA_DCR_SSIZE(1)             // 1 = 8-bit transfers                    | DMA_DCR_DSIZE(1)           // 1 = 8-bit transfers                    | DMA_DCR_D_REQ_MASK                    | DMA_DCR_SINC_MASK                    | DMA_DCR_CS_MASK                    | DMA_DCR_EADREQ_MASK                    );             // Set destination address       DMA_DAR1 = (uint32_t)&I2C_C1_REG(base); Once the DMA channels are initialized, the only action left is to configure the interrupts, enable the channel in the DMA MUX, and create the semaphore if it has not already been created.  This is done as shown below. //Need to enable the DMA IRQ       NVIC_EnableIRQ(DMA0_IRQn);       //////////////////////////////////////////////////////////////////////////       // MUX configuration       // Enables the DMA channel and select the DMA Channel Source        DMAMUX0_CHCFG0 = DMAMUX_CHCFG_SOURCE(BOARD_I2C_DMAMUX_CHN); //DMAMUX_CHCFG_ENBL_MASK|DMAMUX_CHCFG_SOURCE(0x31); //0xb1;       DMAMUX0_CHCFG0 |= DMAMUX_CHCFG_ENBL_MASK;             /* Create semaphore */       if(semDmaReady == NULL){         semDmaReady = OSA_EXT_SemaphoreCreate(0);       } Finally, the DMA initialization function also initializes the ack_nak_array.  This is only necessary when implementing the first DMA strategy.  The second DMA strategy would only need to write a single value at the correct time.  The array initialization for strategy #1 is shown below.  Note that the values written to the array are 0xA1 plus the appropriate value of the TXAK bit.  By writing 0xA1, it is ensured that the I2C module will be enabled in master mode with the DMA enable bit set. // Initialize Ack/Nak array       // Need to initialize the Ack/Nak buffer first       for( j=0; j < destArraySize; j++)       {           if(j >= (destArraySize - 2))           {               ack_nak_array[j] = 0xA1 | I2C_C1_TXAK_MASK;           }           else           {               ack_nak_array[j] = 0xA1 & (~I2C_C1_TXAK_MASK);           }       } DMA Interrupt Handler Now a DMA interrupt handler is required.  A minimum of overhead will be required for this example as the interrupt handler simply needs to service the DONE bit and post the semaphore created in the initialization.  The DMA interrupt handler is as follows: void DMA0_IRQHandler(void) {     // Clear pending errors or the done bit     if (((DMA_DSR_BCR0 & DMA_DSR_BCR_DONE_MASK) == DMA_DSR_BCR_DONE_MASK)         | ((DMA_DSR_BCR0 & DMA_DSR_BCR_BES_MASK) == DMA_DSR_BCR_BES_MASK)         | ((DMA_DSR_BCR0 & DMA_DSR_BCR_BED_MASK) == DMA_DSR_BCR_BED_MASK)         | ((DMA_DSR_BCR0 & DMA_DSR_BCR_CE_MASK) == DMA_DSR_BCR_CE_MASK))     {         // Clear the Done MASK and set semaphore, dmaDone         DMA_DSR_BCR0 |= DMA_DSR_BCR_DONE_MASK;         //dmaDone = 1;         OSA_SemaphorePost(semDmaReady);     } } Using your newly written driver function Once all of these items have been taken care of, it is now time for the application to use the functions. It is expected that the DMA will be initialized before calling the DMA receive function.  After the first call, the DMA can be re-initialized every time or could simply be reset with the start address of the arrays and byte counter (this is the minimum of actions that must be performed).  Then the application should ensure that the transaction happened successfully.   Upon a successful call to the I2C_DRV_MasterReceiveDataDMA function, the application should wait for the semaphore to be posted.  Once the semaphore posts, the application software should wait for the Transfer Complete flag to become set.  This ensures that the application does not try to put a STOP signal on the bus before the NAK has been physically put on the bus.  If the STOP signal is attempted out of sequence, the I2C module could be put in an erroneous state and the STOP signal may not be sent.  Next, the I2C_DRV_CompleteTransferDMA function should be called to send the STOP signal and to signal to the driver structures that the bus is idle.  At this point, the I2C transaction is now fully complete and there is still one data byte that hasn't been transferred to the receive buffer.  It is the application's responsibility to perform one last read of the Data register to receive the last data byte of the transaction. /* Now initialize the DMA */    dma_init(BOARD_I2C_INSTANCE, Buffer, ack_nak_buffer, FXOS8700CQ_READ_LEN); //Init DMAMUX       returnValue = I2C_DRV_MasterReceiveDataDMA(BOARD_I2C_INSTANCE, &slave,                                                   cmdBuff, 1, Buffer, FXOS8700CQ_READ_LEN, 1000); if (returnValue != kStatus_I2C_Success)    {        return (kStatus_I2C_Fail);    } /* Wait for the DMA transaction to complete */    OSA_SemaphoreWait(semDmaReady, OSA_WAIT_FOREVER);       /* Need to wait for the transfer to complete */ for(temp=0; temp<250; temp++)     {         if(I2C_HAL_GetStatusFlag(base, kI2CTransferComplete))         {             break;         }     }       /* Now complete the transfer; this includes sending the I2C STOP signal and       clearing the DMA enable bit */    I2C_DRV_CompleteTransferDMA(BOARD_I2C_INSTANCE);       // Once the Transfer is complete, there is still one byte sitting in the Data    // register.      Buffer[11] = I2C_D_REG(g_i2cBase[BOARD_I2C_INSTANCE]); Conclusion To summarize, as consumers demand more and more power efficient technology with more and more functionality, MCU product developers need to cram more functionality in small power efficient MCUs.  Relying on DMA for basic data transfers is one good way to improve performance of smaller power efficient MCUs with a single core. This can be particularly useful in applications where an MCU needs to pull information from and I2C sensor.  To do this, there are three methods of implementing an I2C master receive function in your SDK 1.3 based application. Use two DMA channels.  The first to transfer from the I2C Data register to the destination array.  A second dedicated DMA channel can be linked to write the I2C_C1 register every time the I2C_D register is serviced. Use two DMA channels.  The first to transfer from the I2C Data register to the destination array. The second DMA channel can be linked to write the I2C_C1 register only after the second to last data byte has been received. Use a single DMA channel can be set to receive two data bytes less than the total number of desired data bytes and the core (application software) can handle the reception of the last two bytes. The recommendation of this document is to implement the first or second option as these are fully automatic options requiring the least intervention by the core.
View full article
The SPI bus has the capability of addressing multiple slave devices by a single master. The Kinetis L series of devices feature either an 8-bit or 16-bit capable SPI module; however, there is only one dedicated CS/SS signal per instance of the module. Of course this signal is muxed to a few pin locations on the device. Unfortunately, there are not that many pins with the CS/SS muxing and they are most likely they are not near to each other physically. A solution to this issue is to use GPIO as CS/SS lines. This way you can take advantage of the SPI bus protocol and the Kinetis L series IOPORT interface (also known as FGPIO on Kinetis L). The Cortex-M0+ allows accesses to the IOPORT to occur in parallel with any instruction fetches; therefore, these accesses will complete in a single cycle. Core vs. SPI I'm sure many who have tried to use GPIO as CS/SS have written code similar to this pseudo code, I know I have: while(1) {      set_cs_low;      send_byte;      set_cs_high; } Logically this makes sense, but on an oscilloscope you will see the GPIO CS/SS line toggling at irregular intervals and out of sync with the SPI transfers. This is due to the nature of the 'send_byte' function or instruction. Simply transmitting a data packet will not prevent the core from waiting for the transmission to complete. The core will move on from writing data to the SPI data register, and execute the next instruction. If you have a core operating at 48 MHz and you are performing, at most depending on instance, 24 MHz SPI transfers the core will always move onto the next instruction before the data has left the module. The code must either implement a delay or wait for the transmission to complete. Incorporating an accurate delay can be tricky and can be interrupted by any interrupts occurring during the delay process. A more robust solution is to wait for the transmission to complete. However, there appears to be no Transmit Complete Flag (TCF) in the L-Series SPI module. The Solution Fortunately, there is a way to wait for transmit complete. Software must wait for the SPI read buffer full flag (SPRF) to be set in the SPI status register (SPIx_S) after writing data to the SPI data register (SPIx_D) . When the SPRF bit is set, software must read the SPIx_D. This procedure will ensure that the core does not move onto GPIO toggling, or other instructions, until the data has left the SPI module. The following function demonstrates how to write the above procedure in C using SPI0 and PTD0 as the CS/SS line: uint8_t SPI_send(uint8_t spiWrite) {     uint8_t spiRead;                        //Variable for storing SPI data     FGPIOD_PCOR |= (1 << 0);                //Toggle CS/SS line low     while(!(SPI0_S & SPI_S_SPTEF_MASK))     {         __asm("NOP");     }                                       //Wait for SPI transmit empty flag to set     SPI0_D = spiWrite ;                            //Write data to SPI     while(!(SPI0_S & SPI_S_SPRF_MASK))     {         __asm("NOP");     }                                       //Wait for receive flag to set     spiRead = SPI0_D;                       //Read the SPI data register     FGPIOD_PSOR |= (1 << 0);                //Toggle CS/SS line high     return spiRead; } Please note that the GPIO CS/SS toggling need not be in the function. It should work just as well if the GPIO CS/SS toggles occur before and after the function is call, just remove the FGPIO instructions from the function and place them outside. I hope this document proves useful to those of you designing multiple slave SPI buses around Kinetis L series parts.
View full article
Introduction The K32L3A60VPJ1AT MCU is a next generation Kinetis dual core device.  This device brings processing and multi-tasking capabilities that legacy Kinetis devices did not support.  In addition, the K32L3A60VPJ1AT offers improved power consumption and security features.   Some important aspects of these security features lie in a nonvolatile information register (IFR) memory region and how this region is programmed.  The IFR memory region is a memory space with restricted access separate from the main array and is comprised of an erasable IFR region and a non-erasable IFR region.  The non-erasable IFR region contains the program once identifier and the version identifier.  The erasable IFR region holds the flash security, flash options, mass erase enable, and other such features that governs how the device behaves.  In legacy Kinetis devices, certain fields of the main flash array (flash addresses 0x400 - 0x40F) configured the IFR at boot time.  In the K32L3A60VPJ1AT however, the IFR memory region is no longer controlled in this manner.  This presents challenges when trying to configure these settings.  The purpose of this document is to explain how these settings can be changed and provide some options of how to make these changes.   The first step in configuring the IFR fields is understanding how the these fields are programmed via the hardware. IFR fields are programmed using a special flash command called the Program Index Command. Once programmed, the flash configuration values cannot be reprogrammed without first erasing these fields.  The only way to erase these values is via a mass erase.  This provides security in that the IFR values cannot be changed without erasing the user code as well.  In addition, changes to the user code image cannot affect the bootloader operation, ensuring that a secure boot function can be executed.  The procedure for writing the erasable IFR values is described here: Write FCCOB0 with the Program Index command (0x43). Write FCCOB1 with the Index to be programmed. The possible Indexes are listed in Erasable IFR Map table (table 16.4.1.2 in the K32L3A6 reference manual). Write FCCOB2 and FCCOB3 with 0x00 as they are not used with this command.  Write FCCOB4 - FCCOBB with the desired value.  (Note that not all of the indexes use all of the FCCOB fields.  Be sure to consult the Erasable IFR Map table for which FCCOB fields are used for the index you are programming).  Write 0x70 to the Flash status register (FSTAT) to clear any errors that might have been present from the last flash command. (Note that this command MUST be a byte write.) Write 0x80 to the Flash status register (FSTAT) to initiate the programmed flash command. Poll the FSTAT register until the CCIF bit field (bit field 7) is one ('1').  (Note that it may not be possible in your scripting language to do this, or it may just be easier to simply wait for the flash command to finish executing. In these cases, wait significantly longer than the typical Program Index command completion time of 110us.) After the IFR has been programmed, the IFR should be read back to verify that it completed correctly.  The process for this is as follows: Write FCCOB0 with the Read Index command (0x41). Write FCCOB1 with the Index to be read.   The possible Indexes are listed in Erasable IFR Map table (table 16.4.1.2 in the K32L3A6 reference manual). Write FCCOB2 - FCCOBB with 0. The results will be stored in FCCOB4 - FCCOBB so, these should be cleared to ensure correct results are received. Write 0x70  to the Flash status register (FSTAT) to clear any errors that might have been present from the last flash command. Note that this command MUST be a byte write. Write 0x80 to the Flash status register (FSTAT) to initiate the programmed flash command . Poll the FSTAT register until the CCIF bit field (bit field 7) is one ('1').  (Note that it may not be possible in your scripting language to do this, or it may just be easier to simply wait for the flash command to finish executing. In these cases, wait significantly longer than the maximum Read Index command completion time of 35us.) When using the Program Index Command, you must know which index you want to modify to create the correct flash commands.  The index list can be found in the IFR descriptions section of the Flash chapter in the K32L3A60VPJ1AT reference manual.   There are several different options for programming the FOPT fields. These options are: Using the Kinetis Flash Tool  Using blhost Debugger script Subroutine in user software Option #1: Kinetis Flash Tool Using the Kinetis Flash Tool is likely the most convenient method to change the IFR values.  The Kinetis Flash Tool uses either the UART or USB protocol to interface with the K32L3A6 bootloader and write the IFR fields desired. One of the biggest advantages for the Kinetis Flash Tool is that it provides a graphical interface for users to easily program the IFR fields. The following figure is a picture of the Kinetis Flash Tool and highlights the important input controls and tabs to be used when programming the IFR fields: This field is the Port set box.  It selects the interface (UART or USB) to be used when communicating to the bootloader.  This box also allows for configuration of the interface.  Consult the K32L3A6 reference manual for default configurations.   This is the Flash Utilities tab.  Select this tab to see the controls shown in this image.  This is the Index input field.  The Index of the IFR to program should be entered here.  This is the Hex digits field.  This value will be programmed at the IFR Index indicated in the Index field. The value here should be in hex format WITHOUT the preceding "0x".   This is the Byte Count field.  This tells the utility how many bytes to program and must be the byte count of that IFR field.  Consult the Erasable IFR Map table in the reference manual for the value of the specific IFR index to be programmed.   This is the Program button.  After all of the fields have been filled out, click this button to program the desired IFR location.  Option #2: BLHOST The MCUBoot package also includes a command line executable to interface with the bootloader.  This tool, blhost, can be used to program the IFR fields as well.  The "flash-program-once" command should be used to program the desired IFR location.  The syntax of this command is as follows: flash-program-once <index> <byteCount> <data> So for example, if you want to program the FOPT IFR field (record index 0x84) with 0xFFFFF3FF, the correct syntax using this command would be flash-program-once 0x84 4 FFFFF3FF After programming, the "flash-read-once" command can be used to read back and verify the programmed IFR field(s).  Below is an example using the previous IFR locations flash-read-once 0x84 4 Below is a full example of erasing the device, programming the FOPT IFR, and reading the FOPT IFR back from the command line using blhost.   Option #3: Debugger Script A simple debugger script is another convenient way to write the IFR values.  Debugger scripts are executed in the background of the debug session initiation process (therefore are hidden operations from the user) and typically can be edited easily using any text editor.  However, it can be cumbersome to change the value because this generally must done manually with each programming by the user. With that in mind, it is a good idea to have different connect scripts for different configurations The first step in using a debugger script is writing a debugger script.  The capabilities and syntax of a debugger script are dependent on your toolchain. For the purposes of this document, we will focus on MCUXpresso IDE.  MCUXpresso IDE uses the PokeXX and PeekXX (where XX is 8, 16, or 32 depending on whether you want to byte access, half-word or word access to the desired register) commands, which are debugger agnostic. So the same commands that work on a device will continue to work whether you are debugging with a JLink or CMSIS-DAP, or whatever other debugger you are using. Below is an example of a MCUXpresso connect script which writes the FOPT register and then reads it back for printing to the debug log.  5140 REM ====================Program FOPT=================================== 5150 Poke32 this 0x40023004 0x43840000 5160 REM Stuff FCCOB registers with desired FOPT value 5170 Poke32 this 0x40023008 v% 5171 s% = Peek32 this 0x40023008 5172 Print "New Val ";~s% 5180 Poke32 this 0x4002300c 0x00000000 5180 Poke8 this 0x40023000 0x70 5190 Poke8 this 0x40023000 0x80 5200 wait 1000 6000 REM ================== Read FOPT ===================================== 6001 REM Now read the FOPT back 6010 Poke32 this 0x40023004 0x41840000 6020 Poke32 this 0x40023008 0x00000000 6030 Poke32 this 0x4002300c 0x00000000 6040 Poke8 this 0x40023000 0x70 6050 Poke8 this 0x40023000 0x80 6060 wait 1000 6070 s% = Peek32 this 0x40023008 6080 Print "New FOPT Val ";~s%   Note in the above script that v% is the desired FOPT value and it has been defined in sections of the script not shown (at line 164).  162 REM This is the value to be written to the FOPT 164 v% = 0xfffff3ff After the script is written, MCUXpresso must be told to use the connect script.  This is done in the Debug Configurations window.  Assuming a debug configuration has already been created, click on the arrow next to the green bug icon and select Debug Configurations.   In the resulting dialog box, select the debug configuration you want to use, and select the Linkserver Debug tab.  In the Connect Script field, point MCUXpresso to the location of your connect script.   That's all that needs to be done in the IDE. The selected debug configuration should now be using the script which was written.   Some debuggers will allow standalone command line running of a script, such as a JLink debugger.  As the JLink is one of the more popular external debuggers that we encounter, an example of programming using this script has been provided below.   // Now Program the FOPT w4 0x40023004, 0x43840000 // The 43 selects the Program Index command. The 84 selects the FOPT IFR field. // Stuff the FCCOB registers (4-7) with the FOPT value we want to write. // ** (Boot Settings) ** w4 0x40023008, 0xfffff3ff // Write 0xFFFF_1FFF to boot the M4 from internal Flash. Asserting the NMI pin will force booting from the ROM. // Write FCCOB registers 8-B with dummy values. w4 0x4002300c, 0x00000000 // Write the FSTAT register to clear any errors that could have been present. w1 0x40023000, 0x70 // Launch the flash command. w1 0x40023000, 0x80 // Wait for the flash command to finish. Sleep 1 // Now Read the FOPT back w4 0x40023004, 0x41840000 // The 43 selects the Program Index command. The 84 selects the FOPT IFR field. // Stuff the FCCOB registers (4-7) with the FOPT value we want to write. // ** (Boot Settings) ** w4 0x40023008, 0x00000000 // Write 0xFFFF_F1FF to boot the M0+ from internal Flash. Asserting the NMI pin will force booting from the ROM. // Write FCCOB registers 8-B with dummy values. w4 0x4002300c, 0x00000000 // Write the FSTAT register to clear any errors that could have been present. w1 0x40023000, 0x70 // Launch the flash command. w1 0x40023000, 0x80 // Wait for the flash command to finish. Sleep 1 // Read the memory back to verify the FOPT settings that should be present after reset. mem32 40023000,4 Option #4: Subroutine in User Software Occasionally the requirements of your system will prevent implementation of any of the above methods to program the IFR values.  In these cases, you may need to implement your own subroutine to program the IFR.  The procedure to do this is essentially the same as in the debugger script methods, just written in code instead of an external script.  One key to remember is that you likely will need to erase the entire flash.  So this subroutine should be placed in RAM memory.  Because flash operations are executing, being in RAM will prevent certain flash errors from occurring.   Conclusion In summary, the IFR registers are nonvolatile information registers that govern certain behaviors of the K32L3A MCU.  The IFR is dividing into an  erasable IFR space and non-erasable IFR space, both of which are not a part of the main flash array.  Programming these values requires the use of special flash commands and requires that these values haven't been previously written since the last mass erase.  There are, in general, four different methods of programming the FOPT register settings.  The four methods are: Kinetis Flash Tool BLhost command line interface Debugger script  User software subroutine Each method has its advantages, therefore, you should pick the one that meets your needs and is most convenient. However with any of the methods chosen, the IFR values must not have been programmed before writing erasable IFR fields. It is best to perform a mass erase (which can be done using any of the methods presented in this document) before attempting to program any IFR fields.     
View full article
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 
View full article
Many customers reported that their ADC function works on FRDM-KL27Z board but meet issue on their own board. We need to pay attention to the difference between the ADC reference voltages of different packages (on board MKL27Z64VLH4 is 64LQFP package). This tip introduce the ADC Reference Options on KL17/KL27 32/36pin package Part number involved: 32-pins 36-pins MKL17Z32VFM4 MKL17Z32VDA4 MKL17Z64VFM4 MKL17Z64VDA4 MKL27Z32VFM4 MKL27Z32VDA4 MKL27Z64VFM4 MKL27Z64VDA4 PTE30/VREF_OUT - connected as the primary reference option on 36-pin and below packages VDDA/VSSA - connected as the VALT reference option   ADCx_SC2[REFSEL] selects the voltage reference source used for conversions.   About the primary reference option : When on-chip 1.2V VREF is enabled, PTE30 pin must be used as VREF_OUT and has to be configured as an analog input, such as ADC0_SE23 (PORTE_PCR30[MUX] = 000). Notice: this pin needs to connect a capacitor to ground.   PTE30 can also be used as an external reference voltage input as long as PTE30 is configured as analog input and VREF module is disabled. It means you can connect external reference voltage to PTE30 pin and use it as ADC reference voltage. (For example 3.3V) KL17P64M48SF2RM     Kinetis KL17: 48MHz Cortex-M0+ 32-64KB Flash (32-64pin) (REV 4.1) KL27P64M48SF2RM     Kinetis KL27: 48MHz Cortex-M0+ 32-64KB Flash (32-64pin) (REV 4.1)
View full article
Test Environment: FRDM-KL43Z Rev. A MCUXpresso IDE v10.2.0 MCUXpresso SDK for FRDM-KL43Z V2.4.1(2018-06-18) Create new project in MCUXpresso IDE select [New project...], there will pop the SDK Wizard panel, then select [frdmkl43z]: Then, click [Next] will enter into [Configure the project] panel, we can set the [Project name] and select [flexio_i2s] in [driver]: Click [Finish], the new project was created. In general, the project is based on [hello_world] project with board default console available. In [Project Explorer], we could find the <fsl_flexio_i2s.c> & <fsl_flexio_i2s.h> & <fsl_flexio.c> & <fsl_flexio.h> files in drivers folder: Edit the code The application note AN5397 detailed introduce how FlexIO emulate I2S bus communication. The MCUXpresso SDK <flexio_i2s> driver using the AN5397 showed second solution to use two timers and two shifters. Please check here to get more detailed info. The I2S signal was below, we need to use four FlexIO pins to provide: BCLK, Fss, TxData & RxData. In <pin_mux.c> file, it need to config pin function, we use PTD7 pin provide I2S BCLK clock; PTD6 pin as I2S Frame_sync pin; PTD5 pin as Tx data pin; PTD6 pin as Rx data pin; In <frdmkl43z_flexio_i2s_interrupt_tx.c>,  config flexio_i2s and config the audio frame format: Please check attached source code for the detailed project info. Test result From the actual measured I2S signal, it shows the 8 bytes was sent out:
View full article
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.
View full article
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.
View full article
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:                  
View full article
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.
View full article
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
View full article
Customer requirement and making it happen This hands-on test is coming with the true customer requirement. Customer designs the battery powered device with SLCD display and lowest power consumption is the key requirement. Customer considers the KL43 and wonder the power consumption data about RTC & SLCD modules. So there with below requirements about the test: Run the RTC and SLCD in the lowest possible power mode Display time at SLCD with [00:00] and update every minute via RTC interrupt               One button shall turn on/off the SLCD display Measure the KL43 power consumption data KDS IDE with KSDK V2.0 software According to above requirement, which low power mode should be selected? RTC and SLCD modules should work at this low power mode. From the KL43 reference manual table 7-2 [Module operation in low power modes] with below info:      5. In VLLS0 the only clocking option is from RTC_CLKIN.      7. End of Frame wakeup not supported in LLS and VLLSx. RTC and SLCD modules could work at VLLS1 low power mode with Async operation. Using VLLS1 low power mode, the RTC and SLCD module clock could select OSC32KCLK with below clocking figure: KL43 wake up from VLLS1 low power mode following wake up reset and the software will check the system reset status register to check what kind of reset happens and print related info. LLWU module is used as VLLS1 lower power mode wake up module with two wake up source, one is RTC Alarm interrupt, the other one is PTC3 (SW3). The Reset pin (SW2) also could wake up the VLLS1 low power mode. Test environment introduction Hardware platform using FRDM-KL43Z board with below feature: MKL43Z256VLLZ4 MCU (48 MHz, 256 KB flash memory, 32 KB RAM, 16 KB ROM Dual role USB interface with mini-B USB connector OpenSDA Four-digit segment LCD module Capacitive touch slider Ambient light sensor MMA8451Q accelerometer MAG3110 magnetometer 2 user push buttons Battery-ready, power-measurement access points Arduino R3 compatibility Software platform bases on KSDK V2.0 for FRDM-KL43Z board, which could be downloaded from kex.nxp.com. Attached demo software default path is: C:\Freescale\SDK_2.0_FRDM-KL43Z\boards\frdmkl43z Test software code introduction Below is the software flow chart: Test result SLCD ON with power consumption 2.0uA SLCD OFF with power consumption 1.2uA
View full article
Hi All, Embedded systems industry are tending to optimized their products to offers a better performance in power management, aiming for longer battery life, using low-power modes in the application without reducing functionality. With this in mind, it arises a requirement in these compact devices, power supply monitor. This document will include a brief description of some features available in different power modes of the Kinetis family and it will focus on how we can implement these features, using KSDK 2.0, to monitor power supply voltage and detect when this voltage has fallen at determined value. This document is based MCU K21 but the same principles can be applied to any Kinetis K and L family. It will use KDS 3.2 as IDE and TWR-K21F120M evaluation board as target.   Hope you can find it useful Best Regards Jorge Alcala
View full article
Hello All, Power consumption of devices and implications around designing on embedded systems is a common topic nowadays. Kinetis MCUs offer different power modes to fit user's needs. Among these low power modes, we can find the lowest consumption modes: Low-Leakage Stop (LLS) and Very Low-Leakage Stop modes (VLLS). Attached document provides a brief introduction/explanation on these modes and lists the steps needed to configure MCU to operate in any of these modes. It is a bare-board project for FRDM-KL26Z but same principle applies to other Kinetis families. Also, two projects for KDS v3.2 are attached for reference. I hope you can find them useful! Regards, Isaac
View full article
Problem Analysis and solutions for booting from ROM BOOTLOADER in KL series 1 Abstract      When customer use the kinetis chip KL43, KL27 and KL17 which flash size is above 128K, they have found a problem that if the code boot from the ROM instead of the flash, the application code about the LPUART and I2C will run in abnormal state, especially when use PTA1 as the  LPUART receive pin, UART transmit function has no problem, but when the PTA1 receive the UART data, the code will run to the abnormal area and can’t return back, the code will be crash. This problem only happens on booting from the ROM and the uart and i2c peripheral are enabled in BCA 0x3d0 address, uart peripheral enablement in BCA area will influence the application PTA1 uart receive, i2c peripheral enablement in BCA area will influence the i2c0 module in the application code. If booting from the flash or booting from ROM but the uart and I2C peripheral are disabled in the BCA 0x3d0 address, everything is working ok in the application code.      This document will take the UART problem as an example, give details of the problem reproduction, testing, analysis and the solutions. The I2C problem is the same when booting from the ROM bootloader. 2 Problem reproduction and analysis  Testing preparation: IDE: KDS 和IAR Hardware: FRDM-KL43 Software: 3.0 and KSDK2.0_FRDM-KL43      We mainly reproduce the uart receive problem in two ways: new KDS PE project based on KSDK1.3.0 and official newest sample code package KSDK2.0_FRDM-KL43. 2.1 Problem reproduction in new creating kds project Because the KSDK2.0 still doesn’t support the PE function in the KDS IDE, so we use the KSDK1.3.0 as the PE KSDK to create the new KDS project. 2.1.1 Create KDS KL43 project The new KDS PE project creating is very simple, here just describe the important points which is relate to the UART problem after booting from the ROM. At first create a new KDS PE project which is based on KSDK1.3.0, and choose the chip as MKL43Z256VLH4, select the MCG mode as HIRC, and configure core clock to 48Mhz, bus clock to 24Mhz. Then add the uart module fls_debug_console for testing, because the FRDM_KL43 is using PTA1 and PTA2, the console module can be configured like the following picture, after the module is configured, press the code generation button to generate the project code. Then add the simple code in file main.c main function for testing: char a; for (;;) {                 PRINTF( " test!\n" );                 a= GETCHAR();                 PUTCHAR(a);               } The code function is: printf the “test!” to the COM port in the PC, then wait the uart data, if receive the data, then printf the received data back and run this loop function again.   2.1.2 Add the BCA area    From the KL43 reference manual, we can get that, BCA start address is 0X3C0:     The KDS newly created project didn’t contain the BCA area in the link file, so we need to add this area in the link file and add the BCA data in the start file by ourselves. 2.1.2.1 Divide the BCA flash are in .ld file Add the following code to define the BCA start flash address and the flash size in the ProcessorExpert.ld memory area: m_bca                 (RX)  : ORIGIN = 0x000003C0, LENGTH = 0x00000040 Then add this code in the SECTIONS area:   .bca :            {              . = ALIGN(4);              KEEP(*(.bca)) /* Bootloader Configuration Area (BCA) */              . = ALIGN(4);            } > m_bca At last, the ld file is like this: For the ld file protection, we can change the ld file properties to read-only, then this file won’t be changed to the initial one after building. 2.1.2.2 Add the BCA data in the start file      After add the BCA flash area divide code, we still need to define the BCA data in the start file:    /* BCA Area */     .section .bca, "a"                 .ascii "kcfg"                            // [00:03] tag                 .long 0xFFFFFFFF // [07:04] crcStartAddress                 .long 0xFFFFFFFF // [0B:08] crcByteCount                 .long 0xFFFFFFFF // [0F:0C] crcExpectedValue                 .byte 0x03                                             // [10] enabledPeripherals  I2C and UART                 .byte 0xFF                                              // [11] i2cSlaveAddress                 .short 3000                           // [13:12] peripheralDetectionTimeout (milliseconds)                 .short 0xFFFF                        // [15:14] usbVid                 .short 0xFFFF                        // [17:16] usbPid                 .long 0xFFFFFFFF  // [1B:18] usbStringsPointer                 .byte 0xFF                                              // [1C] clockFlags                 .byte 0xFF                                              // [1D] clockDivider                 .byte 0xFF                                              // [1E] bootFlags                 .byte 0xFF                                              // [1F] reserved*/    More details, please refer to this picture:       So far, we have create the FRDM-KL43 test project which contains the BCA area, and boot from the ROM that can be modified in the flash address 0X40D, bit 6-7 in 0X40D is the BOOTSRC_SEL bits, 00 boot from flash, 10 and 11 boot from ROM, more details about the FOPT, please refer to Table 6-2. Flash Option Register (FTFA_FOPT) definition in reference manual.     2.1.3 Test result and analysis       Now, list the test result after booting from ROM or flash, and boot from ROM but enable the peripherals. Boot from: ROM peripheral Test Result Flash XX OK ROM 0XFF, enable all NO, UART can’t receive 0X08, enable USB Yes, UART can receive 0X04, enable SPI Yes, UART can receive 0X02, enable I2C Yes, UART can receive 0X01, enable LPUART NO, UART can’t receive      From the test result, we can reproduce the problem. The UART receive problem just happens on booting from ROM and the LPUART is enabled, when we run it with debugger, and test it step by step, we can find after the PTA1 have received the data, the code will run to the abnormal area. Note: when debug this code, please choose the JLINK as the debugger, because the P&E tool will protect the FOPT area automatically in the KDS IDE when do debugging, the code will still run from flash, so if customer use the P&E tool, they will found the PTA1 still can receive the data, this is not the real result, but the JLINK won’t protect FOPT area in the KDS IDE, it can reflect the real result.      After using the JLINK as the debugger, and we have found after PTA1 getting data or pulling low, the code will enter to the abnormal area like this:      We can get that the code run to the defaultISR, and display with USB_IRQHander, but this is not really the USB_IRQHander, just caused by the PC abnormal. Normally, it is caused by the missing of interrupt service function.       Now, we test the NVIC data to check which module interrupt caused this, the following picture is the result by enabling the LPUART and I2C peripheral in the ROM BCA area. We can find, even we didn’t do the cpu and peripheral initialization after booting from ROM, there still have peripheral be enabled, what the interrupt is enabled? From the definitive guide to the ARM Cortex-M0.pdf: NVIC_ISER = 0x40000100, Vector46=IRQ30 and vector24=IRQ8 is enabled, it should be not disabled after booting from the ROM. Now check the KL43 reference manual, Table 3-2. Interrupt vector assignments, we can get that the I2C0 and PORTA interrupt is enabled. Checking the PORTA register before do the cpu and peripheral initialization, PTA1 is enabled the port interrupt, and choose Flag and Interrupt on falling-edge.     This can tell us why the PTA1 pin have the problem of uart receive data or give a falling edge in PTA1 will run abnormal, because in default, even we configure the PTA1 as the uart receive function, but the code didn’t clear IRQ and NVIC register, when the signal happens on PTA1 pin, it will caused the PORTA interrupt, but we didn’t add the PORTA interrupt ISR function, it is also not useful to us, then PC don’t know where to go, so it will run abnormal, enter the defaultISR, and can’t recover. If you have interest, you can add the PORTA_IRQHandler function, you will find the code will run to this function. 2.2 Problem reproduction in KSDK2.0 IAR project  Test project: SDK_2.0_FRDM-KL43Z\boards\frdmkl43z\demo_apps\hello_world  Test the official project just to make sure, it is really the chip hardware function, not only the problem from new generated code in KDS.   Because the IAR IDE will protect the 0X400 area, then if we want to modify the FOPT, we need to modify the .board, add –enable_config_write at first.    Then modify the FOPT in startup_MKL43Z.s: __FlashConfig         DCD 0xFFFFFFFF         DCD 0xFFFFFFFF         DCD 0xFFFFFFFF         DCD 0xFFFFFFFE   ; 0xFFFF3FFE   __FlashConfig_End   Because the BCA peripheral area is in default as 0XFF, it enables all the peripheral, we don’t need to define the BCA area independently.  For getting the real test result, we add the NVIC and PORTA_PCR1 register printf code in the main function,    PRINTF("PORTA_PCR1=%X \n", PORTA->PCR[1]);    PRINTF("NVIC=%X \n", NVIC->ICER[0U]); And download the modified KSDK sample code to the chip, after testing, we get this result: hello world. PORTA_PCR1=A0205 NVIC=40000100 It is the same result as the new created project after booting from the ROM, PORTA interrupt and I2C interrupt is enabled, and it caused the PTA1 receive data problem.  3 Solutions and test result 3.1 Solutions      From the Chapter 2 testing and analysis, we can get that UART receive problem is caused by the PORT interrupt and NVIC is enabled after booting from the ROM, this should be caused by exiting the ROM, the ROM forget to disable it. We also can find some descriptions from the KL43 reference manual page 211: So, if customer want to solve this problem, to avoid the application enter to the abnormal area, we can disable the NVIC in the application code like this, the I2C NVIC is the same:     NVIC_DisableIRQ(8);//disable I2C0 interrupt     NVIC_DisableIRQ(30); //disable PTA interrupt 3.2 Test result   From the test result after adding the NVIC I2C and PORTA disable code, we can get the uart can works ok, if you have interest to test, the I2C will also work ok. 4 Conclusion When customer use the kinetis chip KL43, KL27 and KL17 which flash size is above 128K, and want to boot from the ROM and enable the LPUART and I2C in BCA area, please add the NVIC I2C(IRQ8) and PORTA(IRQ30) disable code in the application code:     NVIC_DisableIRQ(8);//disable I2C0 interrupt     NVIC_DisableIRQ(30); //disable PTA interrupt So far, I just find KL43, KL27 and KL17 which flash size is above 128K have this problem, other kinetis chip which have ROM bootloader don’t have this problem.
View full article
With the merger of NXP and Freescale, the NXP USB VID/PID program, which was previously deployed on LPC Microcontrollers, has been extended to Kinetis Microcontrollers and i.MX Application Processors. The USB VID/PID Program enables NXP customers without USB-IF membership to obtain free PIDs under the NXP VID. What is USB VID/PID Program? The NXP USB VID program will allow users to apply for the NXP VID and get up to 3 FREE PIDs. For more details, please review the application form and associated FAQ below. Steps to apply for the NXP USB VID/PID Program Step 1: Fill the application form with all relevant details including contact information. Step 2: NXP will review the application and if approved, will issue you the PIDs within 4 weeks FAQ for the USB VID/PID Program Can I use this VID for any microcontroller in the NXP portfolio? >> No. This program is intended only for the Cortex M based series of LPC Microcontrollers and Kinetis Microcontrollers, and Cortex A based series of i.MX Application Processors. What are the benefits of using the NXP VID/PID Program? >> USB-IF membership not required >> Useful for low volume production runs that do not exceed 10,000 units >> Quick time to market Can I use the NXP VID and issued PID/s for USB certification? >> You may submit a product using the NXP VID and issued PID/s for compliance testing to qualify to use the Certified USB logo in conjunction with the product, but you must provide written authorization to use the VID from NXP at the time of registration of your product for USB certification. Additionally, subject to prior approval by USB-IF, you can use the NXP VID and assigned PID/s for the purpose of verifying or enabling interoperability. What are the drawbacks of using the NXP VID/PID program? >> Production run cannot exceed 10,000 units. See NXP VID application for more details. >> Up to 3 PIDs can be issued from NXP per customer. If more than 3 PIDs are needed, you have to get your own VID from usb.org: http://www.usb.org/developers/vendor/ >> The USB integrators list is only visible to people who are members of USB-IF. NXP has full control on selecting which products will be visible on the USB integrators list. How do I get the VID if I don't use NXP’s VID? >> You can get your own VID from usb.org. Please visit http://www.usb.org/developers/vendor/ Do I also get the license to use the USB-IF’s trademarked and licensed logo if I use the NXP VID? >> No. No other privileges are provided other than those listed in the NXP legal agreement. If you wish to use USB-IF’s trademarked and licensed USB logo, please follow the below steps:                 1. The company must be a USB vendor (i.e. obtain a USB vendor ID).                 2. The company must execute the USB-IF Trademark License Agreement.                 3. The product bearing the logo must successfully pass USB-IF Compliance Testing and appear on the Integrators List under that company’s name. Can I submit my product for compliance testing using the NXP VID and assigned PIDs? >> Yes, you would be able to submit your products for USB-IF certification by using the NXP VID and assigned PID. However, if the product passes the compliance test and gets certified, it will be listed under “NXP Semiconductors” in the Integrators list. Also, you will not have access to use any of the USB-IF trademarked and licensed USB logos. How long does it take to obtain the PID from NXP? >> It can take up to 4 weeks to get the PIDs from NXP once the application is submitted. Are there any restrictions on the types of devices that can be developed using the NXP issued PIDs? >> This service requireds the USB microcontroller to be NXP products. Can I choose/request for a specific PID for my application? >> No. NXP will not be able to accommodate such requests.
View full article
Porting FatFs file system to KL26 SPI SD card code 1 Abstract      Without the SDHC module, Kinetis KL series need to use the SPI interface to communicate with the SD card. Normally, when customer use the SD card, they are not only want to write and read the SD card, but also prefer to create files(eg, text file, csv file,etc.) in the SD card to record some important data. Use the file to record the data, then the data can be read easily by the PC. MCU need to use the file system to operate the files, the file system should realize the function of file creating, file deleting, file reading and writing, etc. FatFs is a generic FAT/exFAT file system module for small embedded systems. This document mainly describe how to port a FatFs file system to the KL26 SPI SD card code, SD card SPI interface hardware circuit and the SD card basic operation code. 2 FatFs file system introduction 2.1 FatFs feature Windows compatible FAT/exFAT file system. Platform independent. Easy to port. Very small footprint for program code and work area. Various configuration options to support for: Multiple volumes (physical drives and partitions). Multiple ANSI/OEM code pages including DBCS. Long file name in ANSI/OEM or Unicode. exFAT file system. RTOS envilonment. Fixed or variable sector size. Read-only, optional API, I/O buffer and etc... 2.2 FatFs file system organizations   From the above pictures, we can see that in a project with Fatfs module, there mainly 4 parts: application, Fatfs, Disk I/O layer and the Media(SD card). (1) Application, user just need to call the FatFs API function to realize the file creation, read, write and delete. (2) FatFs module, this module contains 6 important files which customer need to use, it is: diskio.c, diskio.h, ff.c, ff.h, ffconf.h, integer.h.  diskio.c and diskio.h is used to call the SD card operation function from the Disk I/O layer, user need to modify this file to match the disk I/O layer, or write the disk I/O layer match this file. ff.c,ff.h is the FatFs file system layer, it defines the API function, user don’t need to modify it. ffconf.h is the system configuration file. integer.h is the data type define file, user don’t need to modify these two files. (3) Disk I/O layer, there has mmc.c and spi.c, actually, the detail name can be defined by the user, it is not fixed. Mmc.c is used to realize the SD card function, eg, SD initialization, SD block writing and reading.  Spi.c is the MCU SPI interface file, it realize the SPI communication function, because the Kinetis series don’t have the SDHC interface, then it use the SPI interface to communicate with the SD card. (4) Media, it can be SD,MMC, USB, NAND flash, here we use the SD card. More details, please refer to FatFs Module application note. 2.3 Common API function f_mount - Register/Unregister a work area of a volume f_open - Open/Create a file f_close - Close an open file f_read - Read data f_write - Write data f_lseek - Move read/write pointer, Expand size f_truncate - Truncate size f_sync - Flush cached data More functions, please go to this link: http://elm-chan.org/fsw/ff/00index_e.html 3 SPI SD operation 3.1 Hardware       This document use the YL_KL26 as the testing board, customer also can add an external SD card circuit to the FRDM-KL26 board. The board is using the TF card, SD SPI interface circuit is:   The pin assignment in the YL-KL26 board is defined as follows: KL26 pin SPI name PTC4 SPI_CS0 PTC5 SPI_SCK PTC6 SPI_MOSI PTC7 SPI_MISO 3.2 Softwave      The test code project is based on the MDK5.1x. 3.3 SD I/O Layer 3.3.1 SD card initialization The communication speed for SD card initialization can’t exceed 400kb/s, if the speed is higher than 400kbps, user need to add the delay in the initialization code, otherwise the initialization will be failure. After the initialization is successful, user can increase the SD card communication speed. Initialization process: (1)  Initialize the SPI interface which connect to the SD card, down to low speed. (2)  Power on delay 72clks, wait for the SD card ready (3)  Go idle state, CMD0, this command will trigger the SD card to use the SPI interface. (4)  Get SD card information, CMD8, get the SD card version. (5) Active the SD card,  with CMD55+CMD41 (6) Read OCR data,CMD59. (7) Set SD card block size to 512Byte. CMD16 (8) Read CSD, get other information, CMD9 (9) Change to high speed and disable the CS uint8 MMCInit(void) {                 uint8 i = 0,k = 0,tmp = 0;                 uint16 cnt=0;                 uint8  buff[512];                                 SSP0LowSpeed();                                      // low speed                 MMCDelayUs(5000);                                                                                   for (i=0; i<0x0F; i++)                               {                    Send_Byte(0xFF);          // send 72 clocks                 }                 // Send Command CMD0 to SD/SD Card  enter idle                 do                 {                     tmp = MMCWriteCmd(CMD0,0x00,0x95);   // CMD0                      k++;                 }while ((tmp != 1) && (k < 200));                                   if(k == 0)                 {                   MMCCS(1);           //cs pullup, disconnect                   Send_Byte(0xFF);                   printf("\n SD reset fail");                   return 1;//                 }                                              //get SD card version                  tmp = MMCWriteCmd( CMD8,0x1AA,0x87 );                  printf( "SD_CMD8  return  %d........\n\n", tmp );  if(tmp == 1)// 2.0 card {          cnt=0xffff;                    do    {     MMCWriteCmd( CMD55, 0, 0xff );     tmp = MMCWriteCmd( CMD41,0x40000000, 0xff);//CMD41      cnt--;    } while ((tmp) && (cnt));                  //Get OCR information                  tmp = MMCWriteCmd(CMD58, 0, 0 );    if ( tmp != 0x00 )    {                   MMCCS(1);           //cs pullup, SD card disconnect                                 printf( "\nSD_CMD58 return  %d....\n", tmp );                   return 1;//    }      for ( i = 0; i < 4; i++ )    {     buff[ i ] = Get_Byte();    }    MMCCS(1);    printf( "OCR return: %x %x %x %x....\n\n", buff[0],buff[1],buff[2],buff[3] );      if ( buff[0] & 0x40 )    {                                  SD_Type = SD_TYPE_V2HC;      printf( "card is V2.0 SDHC.....\n\n" );    }    else {                                  SD_Type = SD_TYPE_V2;      printf( "card is V2.0.....\n\n" );    }              while(MMCWriteCmd(CMD16,512,0xff)!=0);                  MMCWriteCmd(CMD9,0,0xff);   }                 SSP0HighSpeed();                    //back to high speed                 MMCCS(1);                             return 0;                        } 3.3.2 Read one SD card block The block size is 512Byte, the read process is: Send CMD17 and wait the response Receive the start token 0XFE Receive the 512Byte data Receive 2 bytes CRC Disable the CS pin   uint8 MMCReadSingleBolck(uint32 addr,uint8 *buf) {                 uint16 i;                 uint8 sta;                 if(SD_Type!=SD_TYPE_V2HC)                 {                       addr= addr<<9;                 }                 sta = MMCWriteCmd(CMD17,addr,0x01);                 while(sta !=0)                 {                   sta = MMCWriteCmd(CMD17,addr,0x01);                 }                   while (Get_Byte() != 0xFE){;}                   if(sta == 0)                 {                   for (i=0; i<512; i++)                        {                     buf[i] = Send_Byte(0xFF);                   }                            }                 Send_Byte(0xFF);                                                                  Send_Byte(0xFF);                 MMCCS(1);                 return 0; } 3.3.3 Read multiple SD card block uint8 MMCReadMultipleBolck(uint32 addr,uint8 *buf,uint8 count) {          uint16 i;                 if(SD_Type!=SD_TYPE_V2HC)                 {                     addr= addr<<9;                 }                                                 if (MMCWriteCmd(CMD18,addr,0xFF) != 0x00)                    {                     return 1;                                          }                                 MMCCS(0);                 do                 {                     while (Send_Byte(0xFF) != 0xFE){;}                     for (i=0; i<512; i++)                                         {                         *buf++ = Send_Byte(0xFF);                     }                     Send_Byte(0xFF);                                                                                         Send_Byte(0xFF);                                 }while (--count);                 MMCCS(1);                 MMCWriteCmd(CMD12,0x00,0xFF);                   Send_Byte(0xFF);//delay                 return 0; } 3.3.4 Write one SD card block The procedure is: Send CMD24 and wait the response Receive the start token 0XFE Send the 512Byte data Send 2 bytes CRC Disable the CS pin   uint8 MMCWriteSingleBlock(uint32 addr,const uint8 *buf) {                 uint16 i,retry ;                 uint8  temp;                                 if(SD_Type!=SD_TYPE_V2HC)                 {                      addr=addr<<9 ;                 }                                              if (MMCWriteCmd(CMD24,addr,0x01) != 0x00)                         {                     return 1;                                                  }                 MMCCS(0);                 //wait SD card ready                 Send_Byte(0xFF);                          Send_Byte(0xFF);                 Send_Byte(0xFF);                 Send_Byte(0xFE);                               for (i=0; i<512; i++)                                 {                     Send_Byte(buf[i]);                 }                 //Dummy CRC                 Send_Byte(0xFF);                                                                              Send_Byte(0xFF);                 temp = Send_Byte(0xFF);                                                        temp &= 0x1F;                        if (temp != 0x05)                 {                     MMCCS(1);                     return 1;                                                                                                  }                                                 while (Send_Byte(0xFF) == 0x00)                 {                      retry++;                      if(retry>0xfffe)                     {                       MMCCS(1);                        return 1 ;                      }                 }                 MMCCS(1);                 Send_Byte(0xFF);                 return 0; } 3.3.5 Write multiple SD card block uint8 MMCReadMultipleBolck(uint32 addr,uint8 *buf,uint8 count) {     uint16 i;                 if(SD_Type!=SD_TYPE_V2HC)                 {                                   addr= addr<<9;                 }                                                 if (MMCWriteCmd(CMD18,addr,0xFF) != 0x00)                    {                     return 1;                                          }                                 MMCCS(0);                 do                 {                     while (Send_Byte(0xFF) != 0xFE)                     {                         ;                                                                                    }                                     for (i=0; i<512; i++)                                         {                         *buf++ = Send_Byte(0xFF);                     }                                     Send_Byte(0xFF);                                                                                         Send_Byte(0xFF);                                 }while (--count);                                 MMCCS(1);                 MMCWriteCmd(CMD12,0x00,0xFF);                   Send_Byte(0xFF);//delay                 return 0; } 4 FatFs file system porting 4.1 FatFs source code download Go to FatFs official website download the source code, the link is: http://elm-chan.org/fsw/ff/00index_e.html The latest version is FatFs R0.12.    Unzip it, like the following picture, just need 6 files, user can copy it to the project SPI driver folder, and create a new folder named as fatfs. 4.2 Modify diskio.c file We need to modify these functions: disk_initialize:Disk initialize disk_status     :Get the Disk status disk_read       :Read Disk block disk_write      :Write Disk block disk_ioctl       :control device character get_fattime    :Get current time 4.2.1 disk_initialize function DSTATUS disk_initialize (                 BYTE pdrv                                                 ) {                 DSTATUS stat;                    stat=MMCInit();  //SD card initialization                  if(stat == STA_NODISK)                    {                         return STA_NODISK;                     }                 else if(stat != 0)                   {                         return STA_NOINIT;                   }               else                {                      return 0;                         } } 4.2.2 disk_status  function DSTATUS disk_status (                 BYTE pdrv                 /* Physical drive nmuber to identify the drive */ ) {        if(pdrv)     {         return STA_NOINIT;      }                 return RES_OK; } 4.2.3 disk_read function DRESULT disk_read (                 BYTE pdrv,                                /* Physical drive nmuber to identify the drive */                 BYTE *buff,                               /* Data buffer to store read data */                 DWORD sector,        /* Sector address in LBA */                 UINT count                               /* Number of sectors to read */ ) {     DRESULT res;     if (pdrv || !count)     {            return RES_PARERR;      }                           if (count == 1)                  {                                 res = MMCReadSingleBolck(sector,buff);                 }                 else                           {                                 res = MMCReadMultipleBolck(sector,buff,count);                 }     if(res == 0x00)     {         return RES_OK;     }     else     {         return RES_ERROR;     } } 4.2.4 disk_write function DRESULT disk_write (                 BYTE pdrv,                                                /* Physical drive nmuber to identify the drive */                 const BYTE *buff,      /* Data to be written */                 DWORD sector,                        /* Sector address in LBA */                 UINT count                                               /* Number of sectors to write */ ) {                 DRESULT res;                   if (pdrv || !count)     {            return RES_PARERR;      }     if(count == 1)     {         res = MMCWriteSingleBlock(sector, buff);     }     else     {         res = MMCWriteMultipleBlock(sector, buff, count);     }     if(res == 0)     {         return RES_OK;     }     else     {         return RES_ERROR;     } }   4.2.5 disk_ioctl function DRESULT disk_ioctl (                 BYTE pdrv,                                /* Physical drive nmuber (0..) */                 BYTE cmd,                /* Control code */                 void *buff                /* Buffer to send/receive control data */ ) {                 DRESULT res;                 BYTE n, csd[16];                 DWORD csize;                  if (pdrv)                  {                         return RES_PARERR;                  }                 res = RES_ERROR;                 switch (cmd)                 {                     case CTRL_SYNC       : res = RES_OK; break;                     case GET_SECTOR_COUNT: /* Get number of sectors on the disk (WORD) */                                                                 if((MMCWriteCmd(0x49,0x00,0x95) == 0) && MMCCSD_CID(0x49, csd))                                                                 {                                                                 if((csd[0] >> 6) == 1) /* SDC ver 2.00 */                                                                 {                                                                 csize = csd[9] + ((WORD)csd[8] << 😎 + 1;                                                                 *(DWORD*)buff = (DWORD)csize << 10;                                                                 }                                                                 else /* MMC or SDC ver 1.XX */                                                                 {                                                                 n = (csd[5] & 15) + ((csd[10] & 128) >> 7) + ((csd[9] & 3) << 1) + 2;                                                                 csize = (csd[8] >> 6) + ((WORD)csd[7] << 2) + ((WORD)(csd[6] & 3) << 10) + 1;                                                                 *(DWORD*)buff = (DWORD)csize << (n - 9);                                                                 }                                                                 res = RES_OK;                                                                 }                                                                 break;                     case GET_SECTOR_SIZE : /* Get sectors on the disk (WORD) */                                                                    *(WORD*)buff = 512;                                                                    res = RES_OK;                                                                    break;                     case GET_BLOCK_SIZE  :                                                             if ((MMCWriteCmd(0x49,0x00,0x95) == 0) && MMCCSD_CID(0x49, csd)) /* Read CSD */                                                        {                              *(DWORD*)buff = (((csd[10] & 63) << 1) + ((WORD)(csd[11] & 128) >> 7) + 1) << ((csd[13] >> 6) - 1);                                                                        res = RES_OK;                                                        }                                            break;                       default              : res = RES_PARERR; break;                 }                   return res; } 4.2.6 Get_fattime function   This function is used to get the current time, and write it in the file attribute when create, modify the files. It should associate with the RTC, this project didn’t add this function, so just write the code like this: DWORD get_fattime (void) { return 0; } 4.2.7 include SD.h file Comment usb, ATA include files, and add the user SD.h file, this is the SD card IO layer header file. #include "diskio.h"                   /* FatFs lower layer API */ //#include "usbdisk.h"              /* Example: Header file of existing USB MSD control module */ //#include "atadrive.h"            /* Example: Header file of existing ATA harddisk control module */ //#include "sdcard.h"                               /* Example: Header file of existing MMC/SDC contorl module */ #include "SD.h " /* Definitions of physical drive number for each drive */ //#define ATA                           0              /* Example: Map ATA harddisk to physical drive 0 */ //#define MMC                        1              /* Example: Map MMC/SD card to physical drive 1 */ //#define USB                          2              /* Example: Map USB MSD to physical drive 2 */ 4.3 Modify main function This project function is to create two files: Test.csv and Test.txt.  Write four items in these files: Test1, Test2, Test3, Test4. int main (void) {                 uint16 i,j;                 FATFS fs;                               FRESULT fr;                 FIL          fil;                                                            UINT bw;                 char file_name1[12]="Test.csv";                 char file_name2[12]="Test.txt";                 System_init();                 spiInit(SPI0_BASE_PTR , Master);                 fr= f_mount(&fs,file_name1,0);                 if(fr)                 {                                 printf("\nError mounting file system\r\n");                                 for(;;){}                 }                 fr = f_open(&fil, file_name1, FA_WRITE | FA_OPEN_ALWAYS);//create csv file                 if(fr)                 {                                 printf("\nError opening text file\r\n");                                 for(;;){}                 }                 fr = f_write(&fil, "Test1 ,Test2 ,Test3 ,Test4 \r\n", 29, &bw); //write data to the excel file                 if(fr)                 {                                 printf("\nError write text file\r\n");                                 for(;;){}                 }                  fr = f_close(&fil);                 if(fr)                 {                                 printf("\nError close text file\r\n");                                 for(;;){}                 }                 fr= f_mount(&fs,file_name2,0);                 if(fr)                 {                                 printf("\nError mounting file system\r\n");                                 for(;;){}                 }                              fr = f_open(&fil, file_name2, FA_WRITE | FA_OPEN_ALWAYS);//create txt file                 if(fr)                 {                                 printf("\nError opening text file\r\n");                                 for(;;){}                 }                 fr = f_write(&fil, "Test1 ,Test2 ,Test3 ,Test4 \r\n", 29, &bw); //write data to the txt file                 if(fr)                 {                                 printf("\nError write text file\r\n");                                 for(;;){}                 }                 fr = f_close(&fil);                 if(fr)                 {                                 printf("\nError close text file\r\n");                                 for(;;){}                 }            while(1)                 {                          for(i=0;i<10;i++) for(j=0;j<65535;j++);                         printf("\ntest_sd\n");//                 } } Add FatFs header files in the main.h. #include "spi.h" #include "SD.h" #include "diskio.h" #include "ff.h" 5 Test result     After download the code to the KL26 board, then insert a 8G microSD card which already format with the Fat32, press the reset button on the board, user can find the following printf log from the com port: It means the SD card is identified.      Now, take out the SD card and insert it to the PC, user will find there has two files: Test.csv and Test.txt. Open these files, data Test1, Test2, Test3, Test4 can be find in it,  it means the FatFs file system is porting successfully.
View full article
Latest version of the AN2295 universal bootloader includes support for IAR 7.6 IDE. - added support for Kinetis E MCUs - Kinetis K,L,M,E,W,V support
View full article
Hi team ,      I would like to share an experiment that about the Fast IO - zero wait state access of KL series . Detail please refer to attached file . Best regards, David
View full article