Kinetis Microcontrollers Knowledge Base

cancel
Showing results for 
Search instead for 
Did you mean: 

Kinetis Microcontrollers Knowledge Base

Discussions

Sort by:
Revise History: Version 23: NXP kinetis bootloader GUI upgrade from v1.0 to v1.1: added 04 extended linear address record  and 02 sector address record processing for hex format. This article describes how to do in-system reprogramming of Kinetis devices using standard communication media such as SCI. Most of the codes are written in C so that make it easy to migrate to other MCUs. The solution has been already adopted by customers. The pdf document is based on FRDM-KL26 demo board and Codewarrior 10.6.  The bootloader and user application source codes are provided. GUI and video show are also provided. Now the bootloader source code is ported to KDS3.0, Keil5.15 and IAR7.40 which are also enclosed in the SW package. Customer can make their own bootloader applications based on them. The application can be used to upgrade single target board and multi boards connected through networks such as RS485. The bootloader application checks the availability of the nodes between the input address range, and upgrades firmware nodes one by one automatically. ​ Key features of the bootloader: Able to update (or just verify) either single or multiple devices in a network. Application code and bootloader code are in separated projects, convenient for mass production and firmware upgrading. Bootloader code size is small, only around 2K, which reduces the requirement of on chip memory resources. Source code available, easy for reading and migrating. GUI supports S19,HEX and BIN format burning images. For more information, please see attached document and code. The attached demo code is for KL26 which is Cortex - M0+ core. For Cortex-M4 core demo, refer this url: https://community.freescale.com/docs/DOC-328365 User can also download the document and source code from Github: https://github.com/jenniezhjun/Kinetis-Bootloader.git Thanks for the great support from Chaohui Guo and his team. NOTE: The bootloader and GUI code are all open source, users can revise them based on your own requirement. Enjoy Bootloader programming 🙂
View full article
Hi community!! The following example uses a PIT to start an adc conversion, once the conversion has finished it issues a DMA request and the DMA controller stores the converted value in a buffer. The examples were implemented in both CodeWarrior 10.6 and KDS 1.1 for every board. The recommended test circuit is the following: Please feel free to modify the files, I hope this examples will be useful for you and will help you by decreasing your development time. Best Regards Manuel Rodríguez Technical Information Center Intern
View full article
for M68HC08, HCS08, ColdFire and Kinetis MCUs by: Pavel Lajsner, Pavel Krenek, Petr Gargulak Freescale Czech System Center Roznov p.R., Czech Republic The developer's serial bootloader offers to user easiest possible way how to update existing firmware on most of Freescale microcontrollers in-circuit. In-circuit programming is not intended to replace any of debuging and developing tool but it serves only as simple option of embedded system reprograming via serial asynchronous port or USB. The developer’s serial bootloader supported microcotrollers includes 8-bit families HC08, HCS08 and 32-bit families ColdFire, Kinetis. New Kinetis families include support for K series and L series. This application note is for embedded-software developers interested in alternative reprogramming tools. Because of its ability to modify MCU memory in-circuit, the serial bootloader is a utility that may be useful in developing applications. The developer’s serial bootloader is a complementary utility for either demo purposes or applications originally developed using MMDS and requiring minor modifications to be done in-circuit. The serial bootloader offers a zero-cost solution to applications already equipped with a serial interface and SCI pins available on a connector. This document also describes other programming techniques: FLASH reprogramming using ROM routines Simple software SCI Software for USB (HC08JW, HCS08JM and MCF51JM MCUs) Use of the internal clock generator PLL clock programming EEPROM programming (AS/AZ HC08 families) CRC protection of serial protocol option NOTE: QUICK LINKS The Master applications user guides: Section 10, Master applications user guides. The description of Kinetis version of protocol including the changes in user application: Section 7, FC Protocol, Version 5, Kinetis. The quick start guide how to modify the user Kinetis application to be ready for AN2295 bootloader: Section 7.8, Quick guide: How to prepare the user Kinetis application for AN2295 bootloader. Full application note and  software attached.
View full article
Hi everyone! I have made a simple touch sensing demo for KL25z Freedom board for fast user friendly test using MSD bootloader (default combined application in Open SDA when you receive the Freedom - Mass Storage Device and serial port). Demo changes the brightness of red led populated on the board and communicate with FreeMaster visualization tool over embedded virtual serial port of Open SDA connection. Touch sensing application is controlled by TSS (touch sensing softwere). For more information about touch sensing and download of TSS go to www.freescale.com/tss The visualization output has 2 separate scope windows: one showing signals captured from electrodes of slider another one showing position of finger on a slider The operation is really simple, just drag and drop the attached *.s19 file into your device using MSD bootloader (as other precompiled projects for Freedom board) open the *.pmp file that is associated with FreeMASTER, choose the correct COM port at speed of 38400 kbps and start communication The demo was made in CodeWarrior 10.4 using TSS library 3.0.1 in Processor Expert tool, source code can be provided if there will be an interest. There is no need to configure MAP file for FreeMaster communication, application uses so called TSA table - it is position independent this way. If you are not familiar with FreeMASTER or not have it installed in your PC - go to www.freescale.com/freemaster to read more and download the free installer, install it and you are good to run the demo. There are two independent snapshots below, showing the response to my finger movement along the slider Enjoy! and keep in touch
View full article
The Freescale Freedom development platform is a low-cost evaluation and development platform featuring Freescale's newest ARM® Cortex™-M0+ based Kinetis KL25Z MCUs NEW! Quick Start Guide Features: KL25Z128VLK4--Cortex-M0+ MCU with:   - 128KB flash, 16KB SRAM - Up to 48MHz operation  - USB full-speed controller OpenSDA--sophisticated USB debug interface Tri-color LED Capacitive touch "slider" Freescale MMA8451Q accelerometer Flexible power supply options   - Power from either on-board USB connector - Coin cell battery holder (optional population option)  - 5V-9V Vin from optional IO header - 5V provided to optional IO header - 3.3V to or from optional IO header Reset button Expansion IO form factor accepts peripherals designed for Arduino™-compatible hardware
View full article
Hello all.   I would like to share an example project for FRDM-KL25Z board on which C90TFS Flash Driver was included to implement emulated EEPROM (Kinetis KL25 doesn’t have Flex Memory). It is based on the “NormalDemo” example project. A string of bytes is stored on the last page of the flash memory (address 0x1FC00-0x1FFFF), and then, it is overwritten with a different string.   The ZIP file also includes the “Standard Software Driver for C90TFS/FTFx Flash User’s Manual” document. For more information, please refer to Freescale website and search for “C90TFS” flash driver. Hope this will be useful for you. Best regards! /Carlos
View full article
The Real Time Clock (RTC) module is the right tool when we want to keep tracking the current time for our applications. For the Freedom Platform (KL25Z) the RTC module features include: 32-bit seconds counter with roll-over protection and 32-bit alarm 16-bit prescaler with compensation that can correct errors between 0.12 ppm and 3906 ppm. Register write protection. Lock register requires POR or software reset to enable write access. 1 Hz square wave output. This document describes how to implement the module configuration. Also, how to modify the hardware in order feed a 32 KHz frequency to RTC module (it is just a simple wire link).     Hardware. The RTC module needs a source clock of 32 KHz. This source is not wired on the board; hence we need to wire it. Do not be afraid of this, it is just a simple wire between PTC3 and PTC1 and the good news are that these pins are external.   PTC1 is configured as the RTC_CLKIN it means that this is the input of source clock.     PTC3 is configured as CLKOUT (several options of clock frequency can be selected in SIM_SOPT2[CLKOUTSEL] register). For this application we need to select the 32 Khz clock frequency.                         RTC configuration using Processor Expert. First of all we need to set the configurations above-mentioned in Component Inspector of CPU component. Enable RTC clock input and select PTC1 in Pin Name field. This selects PTC1 as RTC clock input. MCGIRCLK source as slow in Clock Source Settings > Clock Source Setting 0 > Internal reference clock > MCGIRCLK source. This selects the 32 KHz clock frequency. Set ERCLK32K Clock Source to RTC Clock Input in Clock Source Settings > Clock Source Setting 0 > External reference clock > ERCLK32K Clock Source. This sets the RTC_CLKIN as the 32 KHz input for RTC module. Select PTC3 as the CLKOUT pin and the CLKOUT pin output as MCGIRCLK in Internal peripherals > System Integration Module > CLKOUT pin control. With this procedure we have a frequency of 32 KHz on PTC3 and PTC1 configured as RTC clock-in source. The MCG mode configurations in this case is PEE mode: 96 MHz PLL clock, 48 MHz Core Clock and 24 MHz Bus clock.   For the RTC_LDD component the only important thing is to select the ERCKL32K as the Clock Source. The image below shows the RTC_LDD component configuration for this application.   After this you only need to Generate Processor Expert Code and write your application.  The code of this example application can be found in the attachments of the post. The application prints every second the current time.     RTC bare-metal configuration. For a non-PEx application we need to do the same configurations above. Enable the internal reference clock. MCGIRCLK is active.          MCG_C1 |= MCG_C1_IRCLKEN_MASK; Select the slow internal reference clock source.          MCG_C2 &= ~(MCG_C2_IRCS_MASK); Set PTC1 as RTC_CLKIN and select 32 KHz clock source for the RTC module.          PORTC_PCR1 |= (PORT_PCR_MUX(0x1));              SIM_SOPT1 |= SIM_SOPT1_OSC32KSEL(0b10); Set PTC3 as CLKOUT pin and selects the MCGIRCLK clock to output on the CLKOUT pin.     SIM_SOPT2 |= SIM_SOPT2_CLKOUTSEL(0b100);     PORTC_PCR3 |= (PORT_PCR_MUX(0x5));   And the RTC module configuration could be as follows (this is the basic configuration just with seconds interrupt): Enable software access and interrupts to the RTC module.     SIM_SCGC6 |= SIM_SCGC6_RTC_MASK; Clear all RTC registers.   RTC_CR = RTC_CR_SWR_MASK; RTC_CR &= ~RTC_CR_SWR_MASK;   if (RTC_SR & RTC_SR_TIF_MASK){      RTC_TSR = 0x00000000; } Set time compensation parameters. (These parameters can be different for each application) RTC_TCR = RTC_TCR_CIR(1) | RTC_TCR_TCR(0xFF); Enable time seconds interrupt for the module and enable its irq. enable_irq( INT_RTC_Seconds - 16); RTC_IER |= RTC_IER_TSIE_MASK; Enable time counter. RTC_SR |= RTC_SR_TCE_MASK; Write to Time Seconds Register. RTC_TSR = 0xFF;   After this configurations you can write your application, do not forget to add you Interrupt Service Routine to the vector table and implement an ISR code.   In the attachments you can find two zip files: PEx application and non-PEx application.   I hope this could be useful for you,   Adrián Sánchez Cano. Original Attachment has been moved to: FRDM-KL25Z-RTC-TEST.zip Original Attachment has been moved to: FRDM-KL25Z-PEx-RTC.zip
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
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
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
Introduction This document is being written to communicate the need for serialization of memory operations and events in an end application.  In addition, directions will be provided to properly serialize memory operations in the end application.  Memory operations and event serialization applies to all Kinetis devices but is only necessary in specific scenarios. These scenarios include memory writes and reads, clearing status flags, and changing mode control operations. Serialization of memory operations Serialization of memory operations or events is the action of guaranteeing that said memory operations or events are executed in a specific order.  This action is required when making a change to a peripheral module when that change must complete before continuing with program execution.  Users often make the mistake of assuming that since a peripheral register has been written to, the change is in effect immediately.  However, this is not always the case.  The Kinetis series devices implement a crossbar and peripheral bridge interface system that allows masters (the CPU, DMA, etc.) to interface with the peripherals.  The crossbar allows multiple masters to access the individual peripherals on the bus, and the peripheral bridge functions as a bus protocol translator between the crossbar switch and the slave peripheral bus.  Wait states can be inserted at either stage of the communication channel (crossbar or peripheral bridge).  When a master attempts to access a slave and another master is already accessing this slave or the slave is busy, wait states will be inserted.  If the access is a write, then the master's write is simply pushed to the peripheral bus and the master continues.  However, if the access is a read, the master must wait for a response from the slave.  The slave may insert wait states in this communication as it must finish any commands (or writes) it was previously given before responding.    Peripheral module changes that require serialization actions include clearing interrupt service flags, changing power modes (of the module or the SOC as a whole), or software triggering a hardware event.  If the events or memory operations are not serialized in these situations, the CPU could go on to execute code with undesired effects. When do I need to serialize my memory operations and events? Memory operations and events require serialization anytime the program needs to guarantee that a peripheral access happens before code execution continues.  Examples of these situations includes: Exiting an interrupt service routine (ISR) Changing a clock mode or power mode Configuring a function Configuring a hardware change Software triggering a hardware event How do I serialize my memory operations and events? Memory operations are serialized by performing the following operations: Write the desired peripheral register Read the peripheral register that was just written Continue with the subsequent operations By simply reading the register that was just written, the core is forced to wait for a response from the peripheral module that was written before code execution can continue.   In this manner, it is guaranteed that the peripheral module will have completed the desired operations. Example event serialization The following is an example of a function that services the LPTMR ISR flag and implements the event serialization discussed in this document.  void lptmr_isr(void) {   // Declare dummy variable to store the read of the LPTMR0_CSR register volatile int dummy_var; /****   STEP #1  ****/   // Clear the flag; enable interrupts; enable the timer   LPTMR0_CSR = ( LPTMR_CSR_TEN_MASK | LPTMR_CSR_TIE_MASK | LPTMR_CSR_TCF_MASK  );   /****  STEP #2  ****/    // Store CSR register in dummy_var to serialize the clearing of the TCF flag   dummy_var = LPTMR0_CSR; } Conclusion In conclusion, there are situations where code execution can continue before a peripheral change has taken effect. These situations include clearing interrupt service flags, changing power modes (of the module or the SOC as a whole), or software triggering a hardware event.   Sometimes these events can cause unexpected results or even cause your application to crash.  These situations call for the serialization of memory operations and events, which is simply the act of guaranteeing that events and code are executed in a specific order.  To serialize memory operations, simply follow these directions: Write the desired peripheral register Read the peripheral register that was just written Continue with the subsequent operations Following these steps, you will be guaranteed that peripheral configurations have taken effect before continuing with the application. 
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 FRDM-KL25Z is an ultra-low-cost development platform enabled by Kinetis L Series KL1 and KL2 MCUs families built on ARM® Cortex™-M0+ processor. Features include easy access to MCU I/O, battery-ready, low-power operation, a standard-based form factor with expansion board options and a built-in debug interface for flash programming and run-control. The FRDM-KL25Z is supported by a range of Freescale and third-party development software. Features MKL25Z128VLK4 MCU – 48 MHz, 128 KB flash, 16 KB SRAM, USB OTG (FS), 80LQFP Capacitive touch “slider,” MMA8451Q accelerometer, tri-color LED Easy access to MCU I/O Sophisticated OpenSDA debug interface Mass storage device flash programming interface (default) – no tool installation required to evaluate demo apps P&E Multilink interface provides run-control debugging and compatibility with IDE tools Open-source data logging application provides an example for customer, partner and enthusiast development on the OpenSDA circuit Take a look at these application notes: USB DFU boot loader for MCUs Developer’s Serial Bootloader. Low Cost Universal Motor Drive Using Kinetis L family . Writing your First MQXLite Application Learn more...
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
The FlexIO module was first introduced in the Freescale Kinetis KL43 family. It is capable of emulating various serial communication protocols including: UART, SPI and I2C. The FlexIO module is very flexible and you can configure it according to your communication needs. The main components of the FlexIO module are the shifters, timers, and pins. Data is loaded onto a shifter and a timer is assigned to generate the shifter clock and use a pin to output the data from the shifter. The KL43 FlexIO module has 4 32-bit shifters, 4 16-bit timers and 8 bidirectional I/O pins. Each shifter and timer has its own configuration registers. The most important registers that configure the whole FlexIO behavior are the SHIFTCFG, SHIFTCTL, TIMCFG, TIMCTL and TIMCMP registers. There are other registers that contain status flags, interrupt enabling bits and the buffers for the shifters. Shifters have a timer assigned to them to generate the shift clock and it can be configured to shift data in or out. When the shifter is configured to transmit mode, the data from the SHIFTBUF register will be loaded to the shifter and the shifter status flag will be set meaning that the shifter is ready to start the transmission. In receive mode, the shifter status flag is set when SHIFTBUF has been loaded with the data from the shifter, and the status flag is cleared when the SHITBUF register is read. The timers are highly configurable, they can use external or internal triggers to generate certain conditions to reset, enable and disable the timer. The triggers can be a timer output, shifter status flag, pin input or an external trigger input. They can be configured to enable in response to a trigger, pin or shifter condition. Each shifter or timer can be configured to use any FlexIO pin with either polarity. The pins can be used as an input or output. A pin configured as an input for a timer can be used to receive a clock and use it as the shifter clock that is assigned to this timer. Once everything is configured you need to read/write the shifter buffers and the shifter and timer status flags to start a transmission or to read the contents of the shifter buffer when receiving data. The following diagram gives a high-level overview of the configuration of FlexIO timers and shifters. Figure 1. FlexIO block diagram In the following example configuration, the FlexIO module will be configured as a transmitter. It will use one shifter, two timers, and three pins. The pins will be used for the outputs of the shifter and the two timers. One timer will be used as the shifter clock and the other timer will be used as a chip select to show when a transmission is being made. The FlexIO will be configured to have a baud rate of FlexIO clock/4 and will do an 8-bit transmission. Figure 2. Example transmission Timer 0 Timer Configuration 0 Register (FLEXIO_TIMCFG0) = 0x00002200 TIMOUT = 0    Timer output is logic one when enabled and is not affected by timer reset. TIMDEC = 0    Decrement counter on FlexIO clock, Shift clock equals Timer output. TIMRST = 0    Timer never reset. TIMDIS = 2    Timer disabled on Timer compare. TIMENA = 2    Timer enabled on Trigger high. TSTOP  = 0    Stop bit is disabled. TSTART = 0    Start bit disabled. Timer Control 0 Register (FLEXIO_TIMCTL0) = 0x01C30101 TRGSEL = 1    Trigger select. Shifter 0 status flag. TRGPOL = 1    Trigger active low. TRGSRC = 1    Internal trigger selected. PINCFG = 3    Timer pin output. PINSEL = 1    Timer pin 1 select. PINPOL = 0    Pin is active high. TIMOD   = 1    Dual 8-bit counters baud/bit mode. Timer Compare 0 Register (FLEXIO_TIMCMP0) = 0x00000F01 TIMCMP = 0x00000F01        Configure 8-bit transfer with a baud rate of FlexIO clock/4. Set TIMCMP[15:8] = (number of bits x 2) - 1. Set TIMCMP[7:0] = (baud rate divider / 2) - 1. In our case we want an 8-bit transfer so TIMCMP[15:8] = 0xF and a baud rate divider of 4 so TIMCMP[7:0] = 0x1. Timer 1 Timer Configuration 1 Register (FLEXIO_TIMCFG1) = 0x00001100 TIMOUT = 0    Timer output is logic one when enabled and is not affected by timer reset. TIMDEC = 0    Decrement counter on FlexIO clock, Shift clock equals Timer output. TIMRST = 0    Timer never reset. TIMDIS = 1    Timer disabled on Timer N-1 disable. TIMENA = 1    Timer enabled on Timer N-1 enable. TSTOP   = 0    Stop bit is disabled. TSTART = 0    Start bit disabled. Timer Control 1 Register (FLEXIO_TIMCTL1) = 0x00030283 TRGSEL = 0    Trigger select. Doesn’t matter because we won’t use a trigger. TRGPOL = 0    Trigger active high. TRGSRC = 0    External trigger selected. PINCFG = 3    Timer pin output. PINSEL = 2    Timer pin 2 select. PINPOL = 1    Pin is active low. TIMOD   = 3    Single 16-bit counter mode. Timer Compare 1 Register (FLEXIO_TIMCMP1) = 0x0000FFFF TIMCMP = 0x0000FFFF Never compare. Shifter 0 Shifter Control 0 Register (FLEXIO_SHIFTCTL0) TIMSEL = 0    Timer 0 select. TIMPOL = 0    Shift on posedge of Shift clock. PINCFG = 3    Shifter pin output. PINSEL = 0    Shifter pin 0 select. PINPOL = 0    Pin is active high. SMOD    = 2    Transmit mode. Load SHIFTBUF contents into the Shifter on expiration of the Timer. Shifter Configuration 0 Register (FLEXIO_SHIFTCFG0) INSRC   = 0    The input source of the shifter is from a pin. In our cause this doesn’t matter because our shifter is set as transmit mode. SSTOP   = 0    Stop bit disabled. SSTART = 0    Start bit disabled. Once all the FlexIO components are configured you have to enable the FlexIO instance by setting the FLEXEN bit in the FLEX_CTRL register. Initially, the shifter status flag is set and is cleared each time the SHIFTBUF register is written. This flag is set each time the SHIFTBUF data has been transferred to the Shifter (SHIFTBUF is empty).  The shifter status flag 0 is configured to be the trigger of the timer 0, so as soon as the status flag is cleared, the timer 0 will be enabled because TIMENA = 2 ( Timer enabled on Trigger high ) and TRGPOL = 1 (Trigger active low). The shifter will begin to shift out the data on the positive edge of the clock ( TIMPOL = 0) until the timer is disabled. The timer will disable when the timer counter reaches 0 ( TIMDIS = 2). The timer 1 is configured to be active (low) when the timer 0 is enabled. This is because TIMDIS = 1 and TIMENA = 1 . The compare register is configured to 16-bit counter and set to 0xFFFF. With this value the timer will never compare and always be active when the timer is enabled. To send data, you have to make sure that the previous transaction was completed and you can check this by reading the TIMSTAT flag. This flag sets each time the timer counter reaches 0. Once the TIMSTAT flag is set, you clear it and write your new data to the SHITBUF register to start the transaction. The KSDK 1.2.0 has drivers and a HAL to facilitate the configuration of the FlexIO module. Some of the important functions are: FLEXIO_DRV_ Init ( uint32_t instance, const flexio_user_config_t * userConfigPtr ); Use this function to initialize the FlexIO module before using it. In this configuration you can change the settings in the FLEXIO_CTRL register such as: Doze Enable, Debug Enable, Fast Access and software reset. FLEXIO_HAL_ ConfigureTimer ( FLEXIO_Type * base, uint32_t timerIdx , const flexio_timer_config_t * timerConfigPtr ); Use this function to configure a timer in the FlexIO. This function uses a configuration structure that can change the TIMCFG, TIMCTL and TIMCPM registers. FLEXIO_HAL_ ConfigureShifter ( FLEXIO_Type * base, uint32_t shifterIdx , const flexio_shifter_config_t * shifterConfigPtr ); Use this function to configure a shifter in the FlexIO. This function uses a configuration structure that can change the SHIFTCFG and SHIFTCTL registers. FLEXIO_HAL_ SetShifterBuffer ( FLEXIO_Type * base, uint32_t shifterIdx , uint32_t value); Use this function to start a transmission. When writing to the SHIFTBUF register, the Shifter Status Flag is cleared. FLEXIO_DRV_ Start ( uint32_t instance); Use this function to enable the FlexIO module by setting the FLEXEN bit in the FLEX_CTRL register. FLEXIO_HAL_ GetTimerStatusFlags ( FLEXIO_Type * base); This function returns the contents of the TIMSTAT register. You can use this function to check when a transmission is finished. FLEXIO_HAL_ ClearTimerStatusFlags ( FLEXIO_Type * base, uint32_t mask); This function clears a specific Timer Status Flag. You can use this function to clear a flag after you read that the flag was set. To change the frequency of the transmission you have to change the value of the TIMCMP register. In dual 8-bit counters baud/bit mode, the lower 8-bits configures the baud rate divider equal to ( CMP[ 7:0] + 1) * 2 and the upper 8-bits configure the number of bits in each word equal to (CMP[15:8] + 1) / 2. In our example the baud rate divider is set to 4, this means CMP[ 7:0] has the value 1. The number of bits transmitted is set to 8, this means CMP[ 15:8] has the value 0xF. Let’s change the baud rate divider to 32. To obtain the CMP[ 7:0] value, we will have to solve the simple equation: 32 = (CMP[7:0]+1)*2 CMP[7:0] = 15=0xF Now let’s change the number of bits to 16. The CMP[ 15:8] value is defined by: 16 = ((CMP[15:8]+1))/2 CMP[15:8] = 31=0x1F The value for the TIMCMP for the timer 0 has to be 0x00001F0F to get a baud rate divider of 32 and a word length of 16 bits. The waveform will look as follows. Figure 3. 16-bit transmission By default the shifter in the FlexIO transmits the LSB first. To change the transmission order, you have to write to the SHIFTBUFBIS (Bit swapped) register instead of the SHIFTBUF register. There are also other buffer registers: SHIFTBUFBYS and SHIFTBUFBBS. The first register swaps the bytes and the second register swaps the bytes and bits at the same time. When using one of these registers you have to be careful to consider that the length of the SHIFTBUF registers is of 32 bits, so if you choose to use the SHIFTBUFBIS for a transmission and your transmission length is not of 32 bits, you have to start writing your data starting from the most significant bit. The following image shows a MSB transmission. The value 0x6AED0000 was written to the SHIFTBUFBIS register. Figure 4 . MSB 16-bit transmission The FlexIO module supports automatic start and stop bit handling. All you have to do is change the SHIFTCFG and the TIMCFG configuration bits. In the SHIFTCFG register set SSTOP to 11 if you want the stop bit to have the value 1, and set the SSTART to 10 if you want the stop bit to have the value 0. In the TIMCFG register set the TSART to 1 and the TSOP to 10. The transmission will look as the following image. Data transmitted 0x0F. Figure 5. Transmission with start and stop bit Changing the phase of the clock is very easy, you just have to set the TIMPOL bit to 1 in the SHIFTCTL register. Figure 6. Shift on negedge of Shift clock The conditions to disable and enable the timers can be configured by changing the TIMENA and TIMDIS values in the TIMCFG register. In our example the timer is enabled by the trigger high. The trigger can be set to be an external pin, a shifter status flag, or a timer output. In our case the trigger was set to the shifter status flag, but you can change this configuration to your communication needs. The timer can also be enabled when the previous timer is enabled, on a certain pin edge, or with a combination of pins and triggers. The timer in the example above disables on the timer compare. This means that when the timer counter reaches zero, the timer will disable automatically. The timer counter is loaded with the timer compare value every time it reaches zero or when it is first enabled.  The timer can also be disabled by other conditions such as: when the previous timer is disabled, on a trigger falling edge, on a pin edge, or on a combination of these. Each pin can be configured to be active high or low. When a pin polarity is changed it only affects the output of the pin, for example, if a timer is set to be the shifter clock and you change the pin polarity, the shifter clock will not change its polarity, only the output to the pin from the timer will change. The configuration for the polarity of the pins is located in the TIMCTL and SHIFTCTL. When the PINPOL value is changed to 1, the pin is active low. In the following image the polarity of the timer pin and the shifter pin was changed to 1, so they are active low. Figure 7. Timer and Shifter active low The FlexIO module can generate an interrupt from 3 sources: Shifter error, Shifter status flag and Timer status flag. To enable the interrupts you need to set the bits in the SHIFTSIEN ,SHIFTEIEN and TIMIEN. If you are using KSDK you can enable the interrupt in NVIC by setting true . useInt in the FlexIO user config that the function FLEXIO_DRV_Init utilizes. The default handler for the interruption is named UART2_FLEXIO_IRQHandler. The following example configuration will configure the FlexIO module as a receiver. This configuration works with the first example configuration shown. Both tower boards (TWR-KL43Z48M) have to be connected as shown further below in the Table 1 Hardware connnections. The FlexIO module will use one Shifter, one timer, and three pins. The pins will be used for the input of the shifter, the input clock for the timer and the trigger for the timer. The timer will use pin 1 as an input and its output will be the same as the input clock. The trigger for the timer will be the transmitter chip select pin and it will be used to enable or disable the timer. The FlexIO will be configured to do an 8-bit transmission. Shifter 0 Shifter Control 0 Register (FLEXIO_SHIFTCTL0) = 0x00800001 TIMSEL = 0    Timer 0 select. TIMPOL = 1    Shift on negedge of Shift clock. PINCFG = 0    Shifter pin output disabled. PINSEL = 0    Shifter pin 0 select. PINPOL = 0    Pin is active high. SMOD    = 1    Receive mode. Captures the current Shifter content into the SHIFTBUF on expiration of the Timer. Shifter Configuration 0 Register (FLEXIO_SHIFTCFG0) = 0x00000000 INSRC   = 0    The input source of the shifter is from a pin. In our cause this doesn’t matter because our shifter is set as transmit mode. SSTOP   = 0    Stop bit disabled. SSTART = 0    Start bit disabled. Timer 0 Timer Configuration 0 Register (FLEXIO_TIMCFG0) = 0x01206602 TIMOUT = 1    Timer output is logic zero when enabled and is not affected by timer reset. TIMDEC = 2    Decrement counter on Pin input (both edges), Shift clock equals Pin input. TIMRST = 0    Timer never reset. TIMDIS = 6    Timer disabled on Trigger rising edge. TIMENA = 6    Timer enabled on Trigger falling edge. TSTOP   = 0    Stop bit is disabled. TSTART = 1    Start bit enabled. Timer Control 0 Register (FLEXIO_TIMCTL0) = 0x04C00103 TRGSEL = 4    Trigger select. Pin 2 input . TRGPOL = 1    Trigger active low. TRGSRC = 1    Internal trigger selected. PINCFG = 0    Timer pin output disabled. PINSEL = 1    Timer pin 1 select. PINPOL = 0    Pin is active high. TIMOD   = 3    Single 16-bit counter mode. Timer Compare 0 Register (FLEXIO_TIMCMP0) = 0x0000000F TIMCMP = 0x0000000F Configure 8-bit transfer. Set TIMCMP = (number of bits x 2) - 1. The shifter status flag is set every time the SHIFTBUF register has been loaded with data from the shifter. This occurs every time that the transmitter sends 8 bits of data. You can read the shifter status flag by polling or by enabling an interrupt based on your needs. This flag clears automatically when you read the SHITBUF register. During the transmission, the first thing that happens is that timer from the receiver will be enabled because the chip select signal from the transmitter is configured as a trigger. Once the timer is enabled, the timer will begin to decrement on the pin input, this means that the shifter clock of the receiver will be equal to the pin input. The transmitter shifter is configured to shift data out on the positive edge of the clock and the receiver shifter is configured to shift data in on the negative edge of the clock. After 8 bits have been transmitted, the compare register from the receiver will reach 0 and this generates an event to store the data from the shifter to the SHITBUF register and the Shifter Status Flag will be set. Finally the timer will be disabled by the chip select signal and keep waiting for another transaction. The hardware connections are shown in the following table. Signal name TWR-KL43Z48M transmitter TWR-KL43Z48M receiver Pin name Board Location Pin name Board Location Serial Data PTD0/FXIO0_D0 B46 PTD0/FXIO0_D0 B46 Clock PTD1/FXIO0_D1 B48 PTD1/FXIO0_D1 B48 Chip Select PTD2/FXIO0_D2 B45 PTD2/FXIO0_D2 B45 GND GND B2 GND B2 Table 1 . Hardware connections Figure 8 . Hardware connections The example projects for the FlexIO transmitter and receiver are developed in KDS 3.0.0 with KSDK 1.2.0. The application lets the user communicate with the transmitter via a serial terminal and the transmitter sends each character to the receiver via FlexIO and the receiver displays the received character on another serial terminal. To be able to compile the project, first you need to compile the library located in C:\Freescale\KSDK_1.2.0\lib\ksdk_platform_lib\kds\KL43Z4. Once the two TWR-KL43Z48M are connected as described above, import both projects into KDS, compile the platform library, and both projects. Open two serial terminals configured to 115200 bauds and run each project on a different tower. On the transmitter terminal you can write anything and it will be displayed and transmitted to the receiver tower via FlexIO and will be shown on the other terminal. Figure 9 . FlexIO example application. Transmitter (left terminal). Receiver (Right terminal). The FlexIO module is also capable of generating a PWM signal by configuring one of its timers to the Dual 8-bit counters PWM mode. This mode is configured by writing 01 to TIMOD in the TIMCTL register. In this mode, the lower 8-bits of the counter and compare register are used to configure the high period of the timer output and the upper 8-bits are used to configure the low period of the timer output. The shifter bit count is configured using another timer or external signal. To calculate the frequency of the PWM signal you have to add the lower 8-bits of the counter and the upper 8-bits and divide it by the FlexIO clock*2 (Only if the timer is configured to decrement on the FlexIO clock.) The frequency of the PWM signal is given by: f = (FlexIO clock)/(TIMCMP[15:8]+TIMCPM[7:0]+2) To calculate the TIMCMP values to get a certain frequency you can solve the equation for TIMCMP TIMCMP[15:8]+TIMCPM[7:0] = (FlexIO clock)/f-2 For example, let’s say we want a 200kHz PWM signal, by using the formula above and using the FlexIO clock of 48MHz, we get that the sum of the TIMCMP values must be 238. If we want a 50% duty cycle we need to write the value 238/2 to the lower and upper 8 bits of the TIMCMP register. The waveform generated by these settings is shown in the figure below. Figure 10. 200kHz 50% duty cycle PWM signal To change the duty cycle you need to change the values of TIMCPM[ 15:8] and TIMCPM[7:0] but without changing the sum of both values, otherwise the frequency will also be altered. For example, if we need a 20% duty cycle we multiply 0.20*238 and 0.8*238. We round up the results and get TIMCPM[ 7:0] = 48 and TIMCPM[15:8] = 190. The waveform generated will look as shown in the figure below. Figure 11. 200kHz 20% duty cycle PWM signal
View full article
The USB OTG module in Kinetis parts uses a Buffer Descriptor Table (BDT) in system memory to manage USB endpoint communications, the BDT is a a 512-byte buffer and there are 3 registers in USB module to contain the base address for it, and it must be 512-byte aligned otherwise there would be issue during transfer. In USB stack ver 4.1.1, some Kinetis old parts like K60N512, K20D72M have the demo project basked on CodeWarrior ARM compiler, and in khci_kinetis.c, bdt is defined as following: #define _BDT_RESERVED_SECTION_ #if (defined _BDT_RESERVED_SECTION_) #ifdef __CWCC__ #pragma define_section usb_bdt ".usb_bdt" RW __declspec (usb_bdt) uint_8_ptr bdt ; but since the base address is defined as below: #define BDT_BASE               ((uint_32*)(bdt)) so the bdt definition is not correct , and we have to change it as below: #define _BDT_RESERVED_SECTION_ #if (defined _BDT_RESERVED_SECTION_) #ifdef __CWCC__ #pragma define_section usb_bdt ".usb_bdt" RW __declspec (usb_bdt) uint_8 bdt[512]; //uint_8_ptr bdt ; and the definition for usb_dbt section can be found in MK20X256_flash.lcf. with above modification, we can make the demo of "msd_mfs_generic" work well as expected. Please kindly refer to the following result got from TWR-K20D72M. FAT demo Waiting for USB mass storage to be attached... Mass Storage Device Attached ****************************************************************************** * FATfs DEMO * * Configuration:  LNF Enabled, Code page =1258 * ****************************************************************************** ****************************************************************************** * DRIVER OPERATION * ****************************************************************************** 1. Demo function: f_mount   Initializing logical drive 0...   Initialization complete ----------------------------------------------------------------------------- 2. Demo functions:f_getfree, f_opendir, f_readdir getting drive 0 attributes............... Logical drive 0 attributes: FAT type = FAT16 Bytes/Cluster = 2048 Number of FATs = 2 Root DIR entries = 512 Sectors/FAT = 250 Number of clusters = 63858 FAT start (lba) = 36 DIR start (lba,clustor) = 536 Data start (lba) = 568 ... 127716 KB total disk space. 127624 KB available. ----------------------------------------------------------------------------- ****************************************************************************** * DRECTORY OPERATION * ****************************************************************************** 1. Demo functions:f_opendir, f_readdir Directory listing...     ----A 2014/04/16 17:25     32253  tek00000.png     ----A 2014/04/16 17:34     31451  tek00001.png     ----A 2014/07/04 14:57     20549  tek00002.png     DR--- 2010/12/25 23:30         0 DIRECT~1     D---- 2010/01/01 00:00         0 DIRECT~2 3    File(s),     84253 bytes total 2    Dir(s) ----------------------------------------------------------------------------- 2. Demo functions:f_mkdir 2.0. Create <Directory_1> 2.1. Create <Directory_2> 2.2. Create <Sub1> as a sub directory of <Directory_1> 2.3. Directory list Directory listing...     ----A 2014/04/16 17:25     32253  tek00000.png     ----A 2014/04/16 17:34     31451  tek00001.png     ----A 2014/07/04 14:57     20549  tek00002.png     DR--- 2010/12/25 23:30         0 DIRECT~1     D---- 2010/01/01 00:00         0 DIRECT~2 3    File(s),     84253 bytes total 2    Dir(s) ----------------------------------------------------------------------------- 3. Demo functions:f_getcwd, f_chdir 3.0. Get the current directory     CWD: 0:/ 3.1. Change current directory to <Directory_1> 3.2. Directory listing Directory listing...     D---- 2010/01/01 00:00         0  .     D---- 2010/01/01 00:00         0  ..     D---- 2010/01/01 00:00         0  sub1 0    File(s),         0 bytes total 3    Dir(s) 3.3. Get the current directory     CWD: 0:/Directory_1 ----------------------------------------------------------------------------- 4. Demo functions:f_stat(File status), f_chmod, f_utime 4.1. Get directory information of <Directory_1>     DR--- 2010/12/25 23:30         0 Directory_1 4.2  Change the timestamp of Directory_1 to 12.25.2010: 23h 30' 20 4.3. Set Read Only Attribute to Directory_1 4.4. Get directory information (Directory_1)     DR--- 2010/12/25 23:30         0 Directory_1 ----------------------------------------------------------------------------- 5. Demo functions:f_rename Rename <sub1> to <sub1_renamed> and move it to <Directory_2> Directory listing...     D---- 2010/01/01 00:00         0  .     D---- 2010/01/01 00:00         0  ..     D---A 2010/01/01 00:00         0 SUB1_R~1 0    File(s),         0 bytes total 3    Dir(s) ----------------------------------------------------------------------------- 6. Demo functions:f_unlink Delete Directory_1/sub1_renamed Directory listing...     D---- 2010/01/01 00:00         0  .     D---- 2010/01/01 00:00         0  .. 0    File(s),         0 bytes total 2    Dir(s) ****************************************************************************** * FILE OPERATION * ****************************************************************************** 1. Demo functions:f_open,f_write, f_printf, f_putc, f_puts, fclose 1.0. Create new file <New_File_1> (f_open)     File size =    0 1.1. Write data to <New_File_1>(f_write) 1.2. Flush cached data     File size =   52 1.3. Write data to <New_File_1> (f_printf) 1.4. Flush cached data     File size =  103 1.5. Write data to <New_File_1> (f_puts) 1.6. Flush cached data     File size =  152 1.7. Write data to <New_File_1> uses f_putc function 1.8. Flush cached data     File size =  199 1.9. Close file <New_File_1> ----------------------------------------------------------------------------- 2. Demo functions:f_open,f_read, f_seek, f_gets, f_close 2.0. Open <New_File_1> to read (f_open) 2.1. Get a string from file (f_gets)     Line 1: Write data to  file uses f_write function 2.2. Get the rest of file content (f_read)     Line 2: Write data to file uses f_printf function Line 3: Write data to file uses f_puts function Line 4: Write data to file uses f_putc functionûöF¬  â•:7Rz}™ yzjw8¸×áÀ—»ÃЭ¹òÍ­ ä ‹ Hïk¨Wã½c'     ²7këÞÑ%VrC×»Ô¼ÒSÈÑèR+NjD¡¾òû>ú3‰SËþo^ÎI Pë±ñ‰þ/Directory_1 [1] 2.3. Close file (f_close) ----------------------------------------------------------------------------- 3. Demo functions:f_stat, f_utime, f_chmod 3.1. Get  information of <New_File_1> file (f_stat)     ----A 2010/01/01 00:00       199  New_File_1.dat 3.2  Change the timestamp of Directory_1 to 12.25.2010: 23h 30' 20 (f_utime) 3.3. Set Read Only Attribute to <New_File_1> (f_chmod) 3.4. Get directory information of <New_File_1> (f_stat)     -R--A 2010/12/25 23:30       199  New_File_1.dat 3.5. Clear Read Only Attribute of <New_File_1> (f_chmod) 3.6. Get directory information of <New_File_1>     ----A 2010/12/25 23:30       199  New_File_1.dat ----------------------------------------------------------------------------- 4. Demo functions:f_ulink Rename <New_File_1.dat> to  <File_Renamed.txt> Directory listing...     D---- 2010/01/01 00:00         0  .     D---- 2010/01/01 00:00         0  ..     ----A 2010/12/25 23:30       199  FILE_R~1.TXT 1    File(s),       199 bytes total 2    Dir(s) ----------------------------------------------------------------------------- 5. Demo functions:f_truncate Truncate file <File_Renamed.txt> 5.0. Open <File_Renamed.txt> to write 5.1. Seek file pointer     Current file pointer:    0     File pointer after seeking:  102 5.2. Truncate file     File size =  102 5.3. Close file ----------------------------------------------------------------------------- 6. Demo functions:f_forward 6.0. Open <File_Renamed.txt> to read 6.1. Forward file to terminal Line 1: Write data to  file uses f_write function Line 2: Write data to file uses f_printf function 6.2. Close file ----------------------------------------------------------------------------- 7. Demo functions:f_ulink Delete <File_Renamed.txt> Directory listing...     D---- 2010/01/01 00:00         0  .     D---- 2010/01/01 00:00         0  .. 0    File(s),         0 bytes total 2    Dir(s) *------------------------------ DEMO COMPLETED    ------------------------ * ******************************************************************************
View full article
In this document we are going to see how to use the attached code which implements the configuration of the FRDM-KL25 board as a USB HOST interfacing with a Numeric Keyboard and a 16x2 LCD. The project is compiled in the CodeWarrior IDE using Processor Expert and the Components to support the USB module of the USB Stack 4.1.1. How to add the Processor Expert USB components. The instructions to install the USB components to use them with Processor Expert are in the documentation of the USB Stack 4.1.1; here you can see the steps as well: Download the USB Stack 4.1.1 from the Freescale’s Website (USB Stack 4.1.1) Run the .exe file and install it in the default location. Open CodeWarrior and select Import Components in the Processor Expert button in menu bar. An Open windows will pop up, there you need to go to the path: <install folder>\Freescale USB Stack v4.1.1\ProcessorExpert\Components. To have the complete components and support for the USB module add each PEupd file repeating this step. Close CodeWarrior and open it again to ensure correct installation of the components. Check that the new components are available in the Components Library. About this Project. This project is based in the example code for Processor Expert in the USB Stack 4.1.1 USB_HID_MOUSE_HOST_MKL25Z128_PEx which implements the use of the FRDM-BOARD KL25 and a HID Mouse Device to interface with. In this project the HID Device is a Numeric Keyboard and the HOST Device (FRDM-KL25) is handling the data and printing them in a 16x2 LCD used in 8 bits mode (The LCDHTA component used here was created by Erich Styger; find the component an all the information about it here: http://mcuoneclipse.com/2012/12/22/hd44780-2x16-character-display-for-kinetis-and-freedom-board/ and say Thank you Erich: “Thank you Erich”). Here you can find a video of the implementation of this application: HID HOST WITH FRDM-KL25 The hardware components are: FRMD-KL25 Rev.E Adafruit Prototype Shield v.5 LCD JHD-162A Numeric USB Keyboard (Product Name: Numpad i110, Model No. GK-100010) USB _host Inside the project you can see there is a folder called USB_Host an it contains two important folders with source files: App_keyboard: Contains the specific function for the Keyboard configuration: in use, attached detached, callbacks and more; contain how to handle the data coming from the device. The function process_kdb_buffer is where the data is transmitted to the LCD and use it for the application. Classes: contain the necessary function to handle a hid as the device. Handle all the functions necessary for the USB protocol. Note: The usb_classes.c and usb_classes.h files are generated by processor expert. I attach these two files as well to have a reference how these files must look like. This is because sometimes during the code generation process Processor Expert erases part of the code. I hope this project is useful for you. Best Regards, Adrian.
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
我们知道Kinetis L系列的中断向量表中只支持两个外部中断向量(vector_46 and vector_47),而FSL早期推出的的KL系列(包括KL25\KL24、KL15\KL14)只有PORTA和PORTD两个IO口支持中断,不过最新推出的KLx6系列(KL26、KL16和KL46)可以支持PORTA、PORTC和PORTD三个IO口的外部中断,其中PORTC和PORTD这两个IO端口共享同一个中断向量,另外,KL0x系列(包括KL02、KL04和L05)由于外部引脚只有PORTA和PORTB两个IO端口,所以它所支持的外部中断只有PORTA和PORTB。 下图分别为KLx5\KLx4系列(不包括KL05\KL04)、KLx6系列和KL05\KL04\KL02的外部中断向量分配表: KLx5\KLx4: KLx6: KL0x: KLx6的头文件注释: 最后需要注意的是,目前所有官方的demo例程(KLxx_SC)的中断向量表vector.h和MKLxxxx.h文件中关于中断向量的注释仍然是PORTA和PORTD,甚至有一部分例程中中断向量表的注释仍然是M4的注释直接移过来的,容易误导客户编程,这点需要在设计PCB板的时候有所考虑。
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