Kinetis Microcontrollers Knowledge Base

cancel
Showing results for 
Search instead for 
Did you mean: 

Kinetis Microcontrollers Knowledge Base

Discussions

1. Introduction MCUboot is a common used bootloader for most of Kinetis and i.mx RT devices. It can support download application via UART/USB/CAN/I2C/SPI. It enables quick and easy programming of Kinetis MCUs and i.mx RT MPU through the entire product life cycle, including application development, final product manufacturing, and beyond. K64 is a very popular device in Kinetis family. It has a M4 core, 512k and above flash, 120M main frequency and plenty of interface, such as I2C/SPI/UART/CAN/USB/ENET. But it is a bit awkward that the MCUboot demo of K64 is not include CAN. Does K64’s CAN can’t support bootloader application? No, of course not. Here we are going to port CAN function to K64 bootloader. There are two kind of CAN peripheral in Kinetis family, FlexCAN and MSCAN. FlexCAN is more complex than MSCAN. K64 has a FlexCAN. To speed up our work, we can port FlexCAN driver and related code from TWR-KV46 bootloader. Hardware: two TWR-SER board two sets of TWR-ELEV TWR-K65F150M TWR-K64F120M   Software: MCUXpresso 11.0 MCUBoot 2.0.0 package SDK_2.6.0_TWR-K64F120M 2. Software porting Step 1, copy below files to twrk64f120m_tower_bootloader project. \drivers\fsl_flexcan.c \drivers\fsl_flexcan.h        \source\bootloader\src\flexcan_peripheral_interface.c   Step 2, modify the project to enable the FlexCAN.       In bootloader_config.h, change BL_CONFIG_CAN definition to 1.        In peripherals_MK64F12.c, add #if BL_CONFIG_CAN     // CAN0     {.typeMask = kPeripheralType_CAN ,      .instance = 0,      .pinmuxConfig = can_pinmux_config,      .controlInterface = &g_flexcanControlInterface,      .byteInterface = &g_flexcanByteInterface,      .packetInterface = &g_framingPacketInterface }, #endif     // BL_CONFIG_CAN       Pin mux setting. In peripherals_pinmux.h, add #define BL_ENABLE_PINMUX_CAN0 (BL_CONFIG_CAN) //! CAN pinmux configurations #define CAN0_RX_PORT_BASE PORTB #define CAN0_RX_GPIO_PIN_NUM 18             // PIN 13 in the PTA group #define CAN0_RX_FUNC_ALT_MODE kPORT_MuxAlt2 // ALT mode for CAN0 RX functionality for pin 13 #define CAN0_TX_PORT_BASE PORTB #define CAN0_TX_GPIO_PIN_NUM 19             // PIN 12 in the PTA group #define CAN0_TX_FUNC_ALT_MODE kPORT_MuxAlt2 // ALT mode for CAN0 TX functionality for pin 12       Set clock. FlexCAN clock source can be OSCERCLK or bus clock. Here we use bus clock run at 48Mhz. In flexcan_peripheral.c, add these code. const flexcan_timing_config_t bit_rate_table48m[] = {     { 23, 3, 4, 4, 4 }, /* 125 kHz */     { 11, 3, 4, 4, 4 }, /* 250 kHz */     { 5, 3, 4, 4, 4 },  /* 500 kHz */     { 3, 3, 4, 4, 4 },  /* 750 kHz */     { 2, 3, 4, 4, 4 }   /* 1   MHz */ }; change line 621 FLEXCAN_SetTimingConfig((CAN_Type *)baseAddr, &bit_rate_table48m[s_flexcanInfo.baudrate]); Step 3, compile the project.   3. Function test Software preparation To connect bootloader via CAN bus, NXP has TWR-K65 as bridge. But its source code is not in K64 SDK. It is in MCUBoot2.0.0 package. User can download the package from https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools/mcuboot-mcu-bootloader-for-nxp-microcontrollers:MCUBOOT The bridge project is called buspal which can be found in NXP_Kinetis_Bootloader_2_0_0\apps\bus_pal\MK65F18. BusPal is an embedded software tool that is available as a companion to blhost. The tool acts as a bus translator with an established connection with blhost over UART and with the target device over I2C, SPI, or CAN, and assists blhost in carrying out commands and responses from the USB target device. The BusPal is available for selected platforms. The source code for BusPal is provided with the Kinetis bootloader release, it support FRDM-KL25, TWR-KV46F150M and TWR-K65F180M and can be customized to run on other platforms. More detail of buspal is in Kinetis blhost User's Guide appendix C.   Hardware connection TWR-SER has TJA1050 as transceiver. We can connect J7 on both boards. When construct the Tower system, user should take care the power. The power tree is very flexible. Improper setting may cause TJA1050 can’t work.   The Buspal project on TWR-K65F180M use UART1 to connect with computer. The port is on TWR-SER. To make the connection simple, we can share the openSDA UART port. The openSDA UART use UART2, we can jump UART1 signal to J33 and J34 on K65 tower board.     Testing: Open a command window, type >blhost -p com4,57600 –buspal can,0,321,123 – get-property 10 This command can check if the whole system work properly. Then, you can download the code to K64 now. Please type >blhost -p com4,57600 –buspal can,0,321,123 – flash-image xxxxxx.s19 erase
View full article
You can put the code directory in the  SDK_2.6.0_FRDM-K64F\boards\frdmk64f to use. 1 、 Introduction As is known to all, we use debugger to download the program or debug the device. FRDMK64 have the opsenSDA interface on the board, so wo do not need other’s debugger. But if we want to design a board without debugger but can download the program, we can use the bootloader. The bootloader is a small program designed to update the program with the interface such as UART,I2C,SPI and so on. This document will describe a simple bootloader based on the FRDMK64F.The board uses SD card to update the application. User can put the binary file into the card. When the card insert to the board ,the board will update the application automatically. The bootloader code and application code are all provided so that you can test it on your own board.   2 、 Bootloader’s implementation   The schematic for SD card is shown below. The board uses SDHC module to communicate with SD card.                                                  Figure 1.Schematic for SD card   We use the 2.6.0 version of FRDM-K64F’s SDK.You can download the SDK in our website. The link is “mcuxpresso.nxp.com”. The bootloader uses SDHC and fafts file system. So we should add files to support it.                   Figure 2.The support file   In main code, the program will wait until the card has inserted. Then it will find the file named “a000.bin” in sd card to update the application. If the file do not exist, the board will directly execute the application. If there is no application, the program will end. The following code shows how the program wait for inserting sd card. It will also check if the address has the application’s address.                      Figure 3.The code -- wait for inserting card   The following code shows how the program opens the binary file. If sd card doesn’t have the file, the program will go to the application. Figure 4.Open the binary file   If the program opens the file normally, the update will begin. It will erase 200k’s space from 0xa000. You can adjust it according to your project. Now I will explain update’s method in detail. Our data is written to the buffer called “rBUff”. The buffer size is 4K. Before write data to it, it is cleared.  Please note that when we erase or program the flash, we should disable all interrupts and when the operations finish we should enable the interrupts.  The file size will decide which way to write the data to flash.  1 、 If the size < 4k ,we just read the file’s data to buffer and judge if its size aligned with 8 byte. If not , we increase the size of “readSize” to read more data in our data buffer called “rBuffer”. The more data we read is just 0.    2 、 If the size > 4K, we use “remainSize” to record how much data is left. We read 4k each time until its size is smaller than 4k and then repeat step 1. When finish the operation at a   time, we should clear the buffer and increase the sector numer to prepare the next transmission. Figure 5.Write flash operation code   The way to clear the space is shown in the figure. It will initialize the flash and erase the given size from the given address.  “SectorNum” is used to show which sector to erase. Figure 6.Erase operation code   The following figure shows how to write the data to flash.              Figure 7.Program operation code     Before we go to the application, we should modify the configuration we did in the bootloader.     Close the systick, clear its value.     Set the VTOR to default value.     Our bootloader runs in PEE mode. So we should change it to FEI mode.     Disable the all pins. You should disable the global interrupt when run these codes. And don’t forget to enable the global interrupt. Figure 8.Deinitalization code   Then we can go to the application. Figure 9.Go to Application   3 、 Memory relocation The FRDMK64 has the 1M flash, from 0x00000000 to 0x00100000.As shown in figure 10,we use the 0xa000 as the application’s start address.            Figure 10.The memory map   Now, I will show you how to modify the link file for user application in different IDE. In IAR                                    Figure 11.IAR’s ICF In MDK Figure 12.MDK’s SCF   In MCUXpresso Figure 13.MCUXpresso’s flash configuration 4 、 Run the demo 1) Download the bootloader first. 2) Prepare a user application program. We use the “led blinky” as an example. 3) Modify the Link file. 4) Generate the binary file with your IDE, please name it as “a000.bin”. 5) Put it into the sd card like figure 5. Figure 14.SD card’s content        6) Insert the card. And power on. Wait for a moment, the application will execute automatically. 5、Reference 1) Kinetis MCU 的 bootloader 解决方案 2) KEA128_can_bootloader
View full article
[中文翻译版] 见附件 原文链接: https://community.nxp.com/docs/DOC-335320
View full article
I have included the files needed to mass erase the flash of the MCU and re-program another binary.   The procedure is shown in the folder " FRDM-KW31_FAT_added_2019" Summarizing you... 1) update the debugger with bootloader mode (press reset and plug in usb cable) drag and drop .sda file on MSD bootloader. 2) unplug and re-plug USB. program the flashloader_loader_mkv31f512.bin by dragging and dropping the binary on to the virtual mass storage device FRDM-KV31 which appear when you plug the USB cable from the FRDM-KV31 to the PC.  3) Open a CMD prompt window and navigate to the folder the files were unzipped to. 4) Determine the COM port by using the device manager 5) from the CMD prompt run the batch file      Erase_KMS_program_bubble.bat COMX
View full article
This years annual hacker security conference known as DEFCON used a couple of NXP devices for this years electronic badge. This document is to explain how to program the device and add extra components. The badge was developed by Grand Idea Studio, with engineering help from NXP, and this presentation has details about the development of the badge. I'm the NXP systems engineer that was helping people get started with reprogramming their badge at Defcon, and wanted to create something that gives all the details on how to do that yourself.  Full schematics and firmware source code can be found at: http://www.grandideastudio.com/defcon-27-badge/   The badge has these two NXP devices:  KL27  - MKL27Z64VDA4 - 48Mhz ARM Cortex M0+ microcontroller w/ 64KB flash (Datasheet and Reference Manual) NXH2261UK- Near Field Magnetic Induction (NFMI) chip for the wireless communication. Has a range on the badge of about 6 inches (15cm), but the technology can work a bit further. It's often found in high end headphones because BLE waves are disrupted by your head but these waves aren't. Also less power consumption. Using the serial port: There's a serial interface which prints out helpful information and there's some "secrets" available if you have a completely leveled up badge. It'll also be really helpful if you're writing new code to hack your badge for printf debugging. Note that you cannot program the board by default over the serial port. This particular chip doesn't support that, though some of our other chips do. It of course would be possible to write a serial bootloader for it, but that's definitely not beginner level. You'll need two pieces of hardware: 1) Header Pins 3) Serial-to-USB converter Header Pin: You can solder on a header to the PCB footprint. Because of the quartz, the leads would need to be flat on the PCB. A   Harwin M20-8770442   will fit the footprint and is what was provided at the soldering village and what you see in the photos below. You could also try creating your own header.  Serial to USB Converter: Since almost no computer today comes with a serial port, a serial to USB converter dongle is needed. It'll have four pins: GND, Power, TX, and RX. The DEFCON badge runs at 1.8V, but the chip itself is rated up to 3.6V, so a 3.3V dongle can be used *as long as you do not connect the power pin on the serial header*. You only need to connect GND, RX, and TX. In a production design you would not want an IO voltage above VCC, but for hacking purposes it'll work, and I've used it all week without an issue on multiple boards.  There's a lot of options. Here's a 1.8V one if you want to be extra cautious or a 3.3V one that already comes with connectors for $8. Anything that transmits at 1.8V or 3.3V will work so you may already have one, but again, just don't connect the power pin.    Software: You'll need to install a serial terminal program like TeraTerm or Putty.  1) Plug the 3.3V or 1.8V USB converter dongle into your computer and it should enumerate as a COM port.  2) Connect the GND line on the dongle to GND on the header 3) Connect the TX pin on the dongle to the RX pin on the header 4) Connect the RX pin on the dongle to the TX pin on the header (it is not RX to RX, I spent 2 whole days tearing my hair out over that during my robotics project in college) 5) DO NOT CONNECT THE POWER PIN  5) Should look like the following when finished 6) In your serial terminal program, connect to the COM port your dongle enumerated as 7) Find the serial port settings menu (in TeraTerm it's in Setup->Serial Port from the menu bar) , and set the baud rate to 115200. The other settings should not need to be changed (8 data bits, no parity, 1 stop bit).  😎 In the terminal, press enter. You should get a > prompt 9) In the terminal, press the '?' key on your keyboard, and hit enter, you'll see the menu.         10) Note that the key you press won't show up in the terminal, but just press Enter and then the command will be run 11) Hit Ctrl+x to exit interactive mode and turn back on the radio.  12) While not in interactive mode, the terminal will display the transmit packet of any badge you bring close to it.  Reprogramming Your Badge: Hardware:  There's two pieces of hardware needed: 1) Programmer/debugger 2) Programming cable Program Debugger: Most any ARM Cortex M debug programmer can be used, as the KL27 chip has a ARM M0+ core. I'd recommend the LPC-Link2 as it's only $20 and can be bought directly from NXP or from most distributors (like Mouser or DIgikey). Search for "OM13054". But you could also use a J-Link, PEMicro, or others if you already have an ARM programmer. Cable: The DEFCON badge has the footprint for a Tag Connect  TC2050-IDC-NL-050-ALL . Because this cable is meant for manufacture programming and not day-to-day debugging, if you plan on stepping through code, you'll also want to pop off the the quartz front and get some retainer clips to keep the programmer connected to the board. If you just simply want to reprogram the board, you can just snip off the 3 long guide clips, and press the cable against the PCB while holding your hand steady for the ~5 seconds it takes to flash it each time.  Alternatively if you already have a JTAG/SWD cable and have soldering skills, you can use some fine gauge wire and hack up your own converter to your board like   /u/videlen   did with some   true hacker soldering . However as   /u/int23h   pointed out, because it's using Single Wire Debug (SWD) you only need to really solder 2 of the pins, SWDIO and SWDCLK. However nRESET is also recommended as it'll let you take control of the device if it's in sleep mode (which it is most of the time). Power (which is needed so the programmer knows what voltage to send the signals at) and GND you can get from the serial header. Software There's three pieces of software you'll need:  1) Compiler 2) MCUXpresso SDK for the KL27  3) Badge source code Compiler: Recommended Option: Latest version of MCUXpresso IDE - available for Windows, Mac, and Linux Second Option: Download older version of MCUXpresso IDE for Windows from the DEFCON media server  Third Option: If you use the latest SDK, you can easily use ARM-GCC, IAR, or Keil tool chains as well.  MCUXpresso SDK: Recommend O ption : Download latest SDK version for KL27 - includes setup for MCUXpresso IDE, ARM-GCC, IAR, and Keil compilers Other option: Download the older 2.4.2 SDK version on the DEFCON server which only has MCUXpresso IDE compiler support.  Badge Source: Recommended O ption : Download zip off Joe Grand Website: http://www.grandideastudio.com/wp-content/uploads/dc27_bdg_source.zip  Other option: Download from DEFCON media server. However the .project and .cproject files do not show up by default, so you must make sure to explicitly download them as well and put them in the main firmware folder (at the same level as the .mex file). These are the exact same files as in the zip.  wget -r -np -R "index.html*" https://media.defcon.org/DEF%20CON%2027/DEF%20CON%2027%20badge/Firmware/ wget  https://media.defcon.org/DEF%20CON%2027/DEF%20CON%2027%20badge/Firmware/.cproject wget  https://media.defcon.org/DEF%20CON%2027/DEF%20CON%2027%20badge/Firmware/.project  Getting Started with MCUXpresso IDE:      1) Open up MCUXpresso IDE. When it asks for a workspace directory to use, select (or make) a new empty directory that is in a different location than where you          downloaded the firmware source.       2) Drag and drop the SDK .zip file from your file system into the MCUXpresso IDE "Installed SDKs" window. This is how the compiler learns about the KL27 device and the flash algorithms.  3) Drag and drop the badge firmware folder from a file explorer window into the MCUXpresso IDE "Project Explorer" window 4) In the Quickstart panel hit Build 5) In the Console tab, you should see the message that it compiled successfully 7) In the Quickstart panel hit Debug.    If you're not using a LPC Link2 for programming, you'll need to hold Shift when clicking this the first time so it'll rescan for your debugger.   If using the latest MCUXpresso IDE, you'll see a dialog box that the launch configuration needs to be updated. Click on "Yes".    7) A dialog box will come up confirming your debug probe. 😎 Connect the programming cable to the board and press to make a good connection. Make sure the alignment pins match up with the alignment holes on the PCB, and that pin 1 (the red stripe) matches the photo below. You may hear the badge beep, as it's being reset. 9) Then hit OK in the dialog box to start programming. Make sure to keep the probe held there until the programming is finished - about 5 seconds. 10) You should see it program successfully and hear the board beep as it reboots.  Programming Troubleshooting/Tips: If you're not using a LPC Link2, hold down the Shift key when you hit the Debug button, and it'll re-search for new probes. Also make sure your debug settings and probe is using SWD mode and not JTAG mode.  If you have the programming cable not lined up with the pads, you'll see this error. Re-align your probe and try again.  Also you must have power from the battery as the MCU needs to be turned on while programming. You can hit the GUI flash programmer at the top for a quicker download experience since it won't load the debug view. Useful if just flashing the device without wanting to step through code.  Finally, some of the game state variables are stored in the non-volitale internal flash, and may not automatically get erased when reprogramming the firmware as the programmer doesn't realize that area of flash memory is being used and thus to save time, doesn't bother to erase it. You can force a complete erase of the flash to wipe all the game variables by setting the mass erase option. Double click on the dc27_badge LinkServer Debug.launch file which contains the debug settings, and go to GUI Flash Tool->Program and set Program (mass erase first).  Getting Started with ARM-GCC: To make this easier, you'll need to download the latest SDK from the NXP website first.  Follow the instructions in Section 6 of the   MCUXpresso SDK User Guide for how to setup the environment and test it out on Hello World. You can then use that project for copying the badge source code into. I'm sure someone can put together a Makefile for the badge specifically. See this series of blog posts   on how to use the SDK (compiling/debugging) with arm-gcc in Linux. My badge isn't working: First thing to try is power cycling the badge by gently prying the battery out (with a butter knife or something) and putting it back in. A couple of things might happen: If nothing at all happens, you battery might be dead. Try replacing the battery.  If nothing at all happens still, the battery holder might be loose. Use a multimeter ot measure the voltage between GND and VCC on the serial header, it should read 1.8V. If it does not, check the battery holder. If you hear beeps, all 6 LEDs light up, and then 4 LEDs (2 on each side) flash in sync a few times, it means there was an issue communicating with the NFMI device. This could be due to a loose solder joint on one of the chips or the I2C pull up resistors (SCL and SDA on the pinout image). You could also do a reflow if you have the equipment, but it may not be fixable. Also could see if see any I2C communication on those SCL/SDA pins. If you hear a normal startup beep, the lights flash, and then it goes back to the startup beep, and so on, forever, something is causing the MCU to keep resetting. Could be a short or ESD damage. Check soldering.  Connecting your board to a serial terminal and see how far it gets in the boot process to help narrow down the cause.  Sometimes the flags don't get saved properly. A power cycle usually works, and could also try reflashing the badge.  If your badge isn't responding to other badges with the NFMI, it could be one of two things: Your copper antenna is loose/broken/missing. This happened a lot. Solder it back on. If missing, it's a Sunlord MTNF6040FS3R7JTFY01 but it's not available online anywhere at the moment. Datasheet is   here.  See   this post   for more details on possible alternatives. If you were previously in interactive mode, you have to explicitly exit it with Ctrl+X to receive packets again.  Further hacking: For basic hacking of the code, try changing your game flags to trick it to giving you a fully unlocked badge. From there, you could try to make your own chameleon badge like others have done (https://github.com/japd06/defcon27_badge   and   https://github.com/nkaminski/DC27-badge-CFW and https://github.com/NickEngmann/Jackp0t   among others if you want ideas). Or make your own songs with the piezo. Or some ASCII art on the terminal. For more advanced hacking on the badge, PTE22 and PTE23, the TX and RX pins on the serial header, could be programmed to be ADC input pins instead. Or timer inputs or outputs for PWM or input capture.  And with some good soldering, you could even add an additional I2C device by soldering to the resistor points. t.   Finally if you want a more flexible platform for exploring embedded development, you can pick up a  FRDM-KL27Z   dev kit for $20 which has the same chip as the badge. You can buy it direct or all major distributors online. The programmer and serial interface are built into the board so you only need to use a USB cable to do all the programming. The KL27 SDK also includes dozens of example programs that show how to use all the features of the chip and there's some getting started videos   (mostly what I covered already in this post though). While it does not have a NFMI chip on it, it does have USB support, as well as an Arduino hardware footprint on it so it can be easily expanded with extra boards. You can find the example programs by going to "Import SDK examples" from the Quickstart panel window.  If you have any more questions about the badge, post a response! 
View full article
The following document contains a list of documents , questions and discussions that are relevant in the community based on the amount of views they are receiving each month. If you are having a problem, doubt or getting started in Kinetis processors or MCUXpresso, you should check the following links to see if your doubt have been already solved in the following documents and discussions. MCUXpresso MCUXpresso Supported Devices Table FAQ: MCUXpresso Software and Tools  Getting Started with MCUXpresso and FRDM-K64F  Generating a downloadable MCUXpresso SDK v.2 package  Quick Start Guide – Using MCUXpresso SDK with PINs&amp;CLOCKs Config Tools  Moving to MCUXpresso IDE from Kinetis Design Studio Kinetis Microcontrollers Guides and examples Using RTC module on FRDM-KL25Z  Baremetal code examples using FRDM-K64F Using IAR EWARM to program flash configuration field Understanding FlexIO  Kinetis K80 FAQ How To: Secure e-mail client (SMTP + SSL) with KSDK1.3 + WolfSSL for FRDM-K64F  Kinetis Bootloader to Update Multiple Devices in a Network - for Cortex-M0+  PIT- ADC- DMA Example for FRDM-KL25z, FRDM-K64F, TWR-K60D100 and TWR-K70  USB tethering host (RNDIS protocol) implementation for Kinetis - How to use your cellphone to provide internet connectivity for your Freedom Board using KSDK Write / read the internal flash Tracking down Hard Faults  How to create chain of pbuf's to be sent? Send data using UDP.  Kinetis Boot Loader for SREC UART, SD Card and USB-MSD loading  USB VID/PID numbers for small manufacturers and such like  Open SDA and FreeMaster OpenSDAv2  Freedom OpenSDA Firmware Issues Reported on Windows 10 Let´s start with FreeMASTER!  The Kinetis Design Studio IDE (KDS IDE) is no longer being actively developed and is not recommended for new designs. The   MCUXpresso   IDE has now replaced the Kinetis Design Studio IDE as the recommended software development toolchain for NXP’s Kinetis, LPC and i.MX   RT Cortex-M based devices. However, this documents continue to receive considerable amount of views in 2019 which means it could be useful to some people. Kinetis Design Studio New Kinetis Design Studio v3.2.0 available Using Kinetis Design Studio v3.x with Kinetis SDK v2.0  GDB Debugging with Kinetis Design Studio  KDS Debug Configurations (OpenOCD, P&amp;E, Segger) How to use printf() to print string to Console and UART in KDS2.0  Kinetis Design Studio - enabling C++ in KSDK projects  Using MK20DX256xxx7 with KDS and KSDK  Kinetis SDK Kinetis SDK FAQ  Introducing Kinetis SDK v2  How to: install KSDK 2.0  Writing my first KSDK1.2 Application in KDS3.0 - Hello World and Toggle LED with GPIO Interrupt 
View full article
The SysTick is a part of the Cortex-M0+ core and so is not chip specific - for details of the Cortex core you generally need to use ARM documents. For SysTick: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0179b/ar01s02s08.html By summary, the SysTick is configured through four registers: 1. SysTick Control and Status(CSR): basic control of SysTick e.g. enable, clock source, interrupt or poll COUNTFLAG: count-down flag, if down to 0, then this bit will be set to 1, otherwise, it will be 0. CLKSOURCE:  when using internal core clock, it will be 1. If using external clock, it will be 0. TICKINT: interrupt enabled when setting to 1. ENABLE: counter enabled when setting to 1. 2. SysTick Reload Value(RVR): value to load Current Value register when 0 is reached. 3. SysTick Current Value (CVR): the current value of the count down. 4.SysTick Calibration Value(CALIB): contain the number of ticks to generate a 10ms interval and other information, depending on the implementation. TENMS: tick value for 10 ms. To configure the SysTick you need to load the SysTick Reload Value register with the interval required between SysTick events. The timer interrupt or COUNTFLAG bit is activated on the transition from 1 to 0, therefore it activates every n+1 clock ticks. If a period of 100 is required 99 should be written to the SysTick Reload Value register. See attached code on how to generate microsecond delay.
View full article
Many customers reported that their ADC function works on FRDM-KL27Z board but meet issue on their own board. We need to pay attention to the difference between the ADC reference voltages of different packages (on board MKL27Z64VLH4 is 64LQFP package). This tip introduce the ADC Reference Options on KL17/KL27 32/36pin package Part number involved: 32-pins 36-pins MKL17Z32VFM4 MKL17Z32VDA4 MKL17Z64VFM4 MKL17Z64VDA4 MKL27Z32VFM4 MKL27Z32VDA4 MKL27Z64VFM4 MKL27Z64VDA4 PTE30/VREF_OUT - connected as the primary reference option on 36-pin and below packages VDDA/VSSA - connected as the VALT reference option   ADCx_SC2[REFSEL] selects the voltage reference source used for conversions.   About the primary reference option : When on-chip 1.2V VREF is enabled, PTE30 pin must be used as VREF_OUT and has to be configured as an analog input, such as ADC0_SE23 (PORTE_PCR30[MUX] = 000). Notice: this pin needs to connect a capacitor to ground.   PTE30 can also be used as an external reference voltage input as long as PTE30 is configured as analog input and VREF module is disabled. It means you can connect external reference voltage to PTE30 pin and use it as ADC reference voltage. (For example 3.3V) KL17P64M48SF2RM     Kinetis KL17: 48MHz Cortex-M0+ 32-64KB Flash (32-64pin) (REV 4.1) KL27P64M48SF2RM     Kinetis KL27: 48MHz Cortex-M0+ 32-64KB Flash (32-64pin) (REV 4.1)
View full article
As most of people familiar with FRDM-K64F which is a bit old but it is still a hot device in the market. This document focused on the ADC measurement to verify the deviation. In general, the sample code were modified /come with MCUXpresso SDK, which is an ADC polling example. ADC reading was done by two ways: 1) Polling the status register of ADC conversion complete flag until ADC conversion is done. 2) CPU core is in sleep right after ADC conversion is started by software trigger. Interrupt is generated when ADC conversion is done and CPU core wakes up by this interrupt. The value of ADC reading is measured 5000 times. And, it is averaged, also calculate max/min value. Finally, the standard deviation is calculated based on the 5000 measured value. PRINTF is a terminal console and print out by semi-hosting. Interrupt method or polling method can been selected by the define of INTERRUPT or POLLING. #define INTERRUPT 0   //ADC conversion wait for “INTERRUPT” should be defined to 1 #define POLLING 1   //ADC conversion wait for “POLLING” should be defined to 1
View full article
The DOC introduces the nano-edge placement  feature for KV4x family, it gives the application for the nano-edge placement feature, in other words, it's target is to increase the PWM signal resolution. It gives the example code and PWM waveform for the nano-edge placement feature.
View full article
For motor control and swich mode power supply application, it is required that the ADC sampling is synchronized with PWM signal. In general, most Kinetis sub-family provides FTM, PDB and ADC, it provides a mechanism for ADC converter is synchronizedc with PWM signal. But the KEA family does not have PDB module, instead, the KEA family provides a simple mechanism which enables PWM signal the FTM module generate can synchronize the ADC converter. The DOC introduces the mechanism, give the register configuration description, code and scope screenshot on how the PWM signal synchronizes the ADC.
View full article
Test environment: FRDM-K64F Rev.D IAR ARM Workbench IDE V8.30.1 MCUXpresso SDK for FRDM-K64F v2.4.2(2018-08-02) Test project is [ftm_output_compare] located with default path: ..\FRDM-K64F\boards\frdmk64f\driver_examples\ftm\output_compare Test reason to verify the CnV register is updated on the next FTM counter change. Three test signals: FTM0_CH0 pin as output compare pin will generate square signal with 1.33KHz . FTM0_CH1 pin generate 24KHz Edge-Aligned PWM signal(High-true pulses (clear Output on match)) with 50% duty cycle as FTM counter monitor. When FTM counter change, the FTM0_CH1 will toggle to output high voltage. Test using a delay() function to emulate modify FTM0_CH0 output compare mode and CnV value periodically. There is a GPIO pin will toggle after each delay() function to detect/verify the CnV value actual load point. FlexTimer module setting: The FTM0 refer clock is 60MHz For the FTM0_CH1 pin generate 24KHz PWM signal, the FTM0 MOD value is fixed to 0x9C3 (60MHz/24KHz = 2500).   Below is the overall signals: Test Process Record: During FTM0 module initialization, set the FTM0_CH0 pin output compare value to 0xA00 (more than MOD register value (0x9C3)) with below code: Set the CnV value more than MOD register is to avoid the output compare be set during at start. After that,  enable FTM0 counter and toggle GPIO pin to set a mark: After delay, toggle GPIO pin and update CnV register to 0x270 (the match point is half of the PWM high voltage). The actual signal is : After the first CH0 output compare set match, before set CH0 pin clear on match. It need to keep the CH0 pin with same output compare mode and set CnV back to 0xA00 (more than MOD) again with below code: Then we set CH0 with clear on match mode and update CnV value to 0x752 (middle of CH1 PWM low voltage): The actual signal is: With the similar code, before next CH0 set on match, it need to keep the CH0 pin with same match compare mode setting and CnV change back to 0xA00 (more than MOD). The actual signal is below: Note: During the output compare signal compare mode set/clear change phase, it need to keep previous output compare mode setting, please don't using kFTM_NoOutputSignal setting at code. Otherwise, the output compare signal will exist decay: Test Result: From FTM0 register value, the FTM0_SYNCONF[SWRSTCNT] bit is clear, which means select Legacy PWM synchronization method. The legacy PWM synchronization method will update Output Compare mode CnV register value at the next FTM counter change. The actual signal also verify it. Below is FTM0 all registers value: For the more detailed info, please check the original thread at here. Please check attachment about test code.
View full article
Test Environment: FRDM-KL43Z Rev. A MCUXpresso IDE v10.2.0 MCUXpresso SDK for FRDM-KL43Z V2.4.1(2018-06-18) Create new project in MCUXpresso IDE select [New project...], there will pop the SDK Wizard panel, then select [frdmkl43z]: Then, click [Next] will enter into [Configure the project] panel, we can set the [Project name] and select [flexio_i2s] in [driver]: Click [Finish], the new project was created. In general, the project is based on [hello_world] project with board default console available. In [Project Explorer], we could find the <fsl_flexio_i2s.c> & <fsl_flexio_i2s.h> & <fsl_flexio.c> & <fsl_flexio.h> files in drivers folder: Edit the code The application note AN5397 detailed introduce how FlexIO emulate I2S bus communication. The MCUXpresso SDK <flexio_i2s> driver using the AN5397 showed second solution to use two timers and two shifters. Please check here to get more detailed info. The I2S signal was below, we need to use four FlexIO pins to provide: BCLK, Fss, TxData & RxData. In <pin_mux.c> file, it need to config pin function, we use PTD7 pin provide I2S BCLK clock; PTD6 pin as I2S Frame_sync pin; PTD5 pin as Tx data pin; PTD6 pin as Rx data pin; In <frdmkl43z_flexio_i2s_interrupt_tx.c>,  config flexio_i2s and config the audio frame format: Please check attached source code for the detailed project info. Test result From the actual measured I2S signal, it shows the 8 bytes was sent out:
View full article
Abstract MK60 is a popular MCU in Kinetis K family. NXP has prepared some kinds of bootloader for TWR-K60D100. But as we all know, MCUBoot2.0.0 is the most update bootloader for Kinetis family. It is a configurable flash programming utility that operates over a serial connection on Kinetis MCUs. It enables quick and easy programming of Kinetis MCUs through the entire product life cycle, including application development, final product manufacturing, and beyond. But sinceTWR-K60D100 is a relatively old platform compare to K22 and K64/K65/K66, MCUBoot2.0.0 did not add MK60 to its target board. If customer don’t like those old bootloader, they have to port it by themselves. This article tries to guide user to port MCUBoot to TWR-K60D100 base on Chapter 10 in Kinetis Bootloader v2.0.0 Reference Manual. This time we use KDS. Software requirement: Kinetis Design Studio 3.2 MCUBootloader 2.0.0 (KBoot 2.0.0) MCUXpresso Config Tools v4.0 SDK_2.2_TWR-K60D100M Porting flow Step 1: First I copy NXP_Kinetis_Bootloader_2_0_0\targets\MK64F12 to NXP_Kinetis_Bootloader_2_0_0\targets\MK60D100. The reason I select MK64 is more likely to MK60 than other target, especially in clock distribution, system integration module and signal multiplexing. In mk60d100\src directory, rename the following files: clock_config_mk64f12.c — > clock_config_mk60d100.c hardware_init_mk64f12.c — > hardware_init _ mk60d100.c memory_map_mk64f12.c — > memory_map _ mk60d100.c peripherals_ mk64f12.c — > peripherals _ mk60d100.c Then copy system_MK60D10.c and system_MK60D10.h from SDK_2.2_TWR-K60D100M to mk60d100\src\startup, copy startup_MK60D10.S from SDK_2.2_TWR-K60D100M to mk60d100\src\startup\gcc. Step 3: Then I copy \src\platform\devices\MK64F12 to \src\platform\devices\mk60d100, copy SDK_2.2_TWR-K60D100M\devices\MK60D10\fsl_device_registers.h, MK60D10.h, and MK60D10_features.h to this new directory. Step 4: Open the KDS project in MK60D100 and replace above old file with new file. After that, I change some setting. Figure 1. Target Processor change   K64 has hardware FPU, but K60D100 hasn’t. So, Float ABI must be changed to software. There is a C/C++ preprocessor define that is used by the bootloader source to configure the bootloader based on the target MCU. This define must be updated to reference the correct set of device-specific header files. Figure 2. Preprocessor change   As to the link file, it needn’t to be change. We can use K64’s link file. TWR-K60D100 use an old version PE debugger. So, the debugger setting must be changed. Figure 3. Debug setting Step 5: MK60’s clock distribution structure is different with MK64. We must modify this part. As it is very complex, use MCUXpresso Config Tools to generate this config code is a sensible choice. Open the tools and step clock structure as below: Figure 4. clock setting After that, generate the code and save them to \src\platform\devices\mk60d100. Since MCUBoot2.0.0 is not base on SDK2.x, we must copy some related driver file from SDK2.x package, include fsl_smc.c, fsl_smc.h, fsl_rtc.c, fsl_rtc.h. Then add them to project. In clock_config_mk60d100.c line 168, the code is clock_mode_switch(s_currentClockMode, kClockMode_FEI_48MHz); Replace it with:      BOARD_BootClockUSB(); // this function was generated by MCUXpresso Config Tool Then add the head file of “clock_config.h”.   Step 6: TWR-K60D100 use UART5 as the debug UART port. Please refer to https://community.nxp.com/docs/DOC-340954 for detail. MCUBootloader2.0.0 do not support UART5. User must add its code in pinmux_utility_common.c.   Step 7: Modify usb_clock_init() in hardware_init_MK60D100.c as below bool usb_clock_init( void ) {    SIM-> SCGC4 &= ~SIM_SCGC4_USBOTG_MASK;      SIM-> CLKDIV2 = ( uint32_t )0x00L;    SIM-> SOPT2 |= SIM_SOPT2_USBSRC_MASK | SIM_SOPT2_PLLFLLSEL(0x01);     //k60 PLLFLLSEL change from 3 to 1      SIM-> SCGC4 |= SIM_SCGC4_USBOTG_MASK;   //   USB0->CLK_RECOVER_IRC_EN = 0x03; //   USB0->CLK_RECOVER_CTRL |= USB_CLK_RECOVER_CTRL_CLOCK_RECOVER_EN_MASK;   //   USB0->CLK_RECOVER_CTRL |= 0x20;      return true; }   Modify memory_map_MK60D100.c as below: memory_map_entry_t g_memoryMap[] = {    { 0x00000000, 0x0007ffff, kMemoryIsExecutable , &g_flashMemoryInterface },   // Flash array (512KB)    { 0x1fff0000, 0x2000ffff, kMemoryIsExecutable , &g_normalMemoryInterface }, // SRAM (256KB) { 0x40000000, 0x4007ffff, kMemoryNotExecutable , &g_deviceMemoryInterface }, // AIPS peripherals      { 0x400ff000, 0x400fffff, kMemoryNotExecutable , &g_deviceMemoryInterface }, // GPIO    { 0xe0000000, 0xe00fffff, kMemoryNotExecutable , &g_deviceMemoryInterface }, // M4 private peripherals    { 0 }                 // Terminator };   Modify bl_uart_irq_config_common.c as below: void UART_SetSystemIRQ( uint32_t instance, PeripheralSystemIRQSetting set) {    switch (instance)    {        case 0: #if (FSL_FEATURE_SOC_UART_COUNT > 1)        case 1: #endif // #if (FSL_FEATURE_SOC_UART_COUNT > 1) #if (FSL_FEATURE_SOC_UART_COUNT > 2)        case 2: #endif // #if (FSL_FEATURE_SOC_UART_COUNT > 2) #if (FSL_FEATURE_SOC_UART_COUNT > 3)        case 3: #endif // #if (FSL_FEATURE_SOC_UART_COUNT > 3) #if (FSL_FEATURE_SOC_UART_COUNT > 4)        case 4: #endif // #if (FSL_FEATURE_SOC_UART_COUNT > 4) #if (FSL_FEATURE_SOC_UART_COUNT > 5)          // add UART5 support        case 5: #endif // #if (FSL_FEATURE_SOC_UART_COUNT > 5)              if (set == kPeripheralEnableIRQ )            {                NVIC_EnableIRQ(uart_irqs[instance]);            }            else            {                NVIC_DisableIRQ(uart_irqs[instance]);            }            break ;    } }   In target_config.h, modify kMaxCoreClock value to 100.   Step 8: After all of the above work, compile the project and download to TWR-K60D100 board. You’ll find KinetisFlashTool.exe can recognize the device by UART. If you establish a Tower system with TWR-SER board, KinetisFlashTool can also recognize the device by USB.   Conclusion: K60 is the base of many Kinetis K series MCU, include K10, K20, K61, K70. If you want to port MCUBoot2.0.0 to these MCU, you just want to update the clock_config file.
View full article
  MCU Bootloader2.0.0 enables quick and easy programming of Kinetis MCUs through the entire product life cycle, including application development, final product manufacturing, and beyond. It supports many kinds of peripherals, include UART, I2C, SPI, USB, CAN and so on. Among these peripherals, UART is most common used. In reference manual, it only says that feature can be turned on or off by using #define statement in bootloader_config.h. In fact, you can use UART0 by default. But if you want to use other UART port, change TERM_PORT_NUM to other value is useless. If you traced this value, you’ll find it is not used at all, nor the TERMINAL_BAUD. Here we use FRDM-KV31F512 as the example. We want to download image by UART2. First, we should modify peripherals_pinmux.h. #define BL_ENABLE_PINMUX_UART2 (BL_CONFIG_SCUART)     //line 38   //! UART pinmux configurations #define UART2_RX_PORT_BASE PORTE #define UART2_RX_GPIO_BASE PTE #define UART2_RX_GPIO_PIN_NUM 17               // PIN 16 in the PTB group #define UART2_RX_FUNC_ALT_MODE kPORT_MuxAlt3   // ALT mode for UART0 RX #define UART2_RX_GPIO_ALT_MODE kPORT_MuxAsGpio // ALT mode for GPIO functionality #define UART2_RX_GPIO_IRQn PORTE_IRQn #define UART2_RX_GPIO_IRQHandler PORTE_IRQHandler #define UART2_TX_PORT_BASE PORTE #define UART2_TX_GPIO_PIN_NUM 16             // PIN 17 in the PTB group #define UART2_TX_FUNC_ALT_MODE kPORT_MuxAlt3 // ALT mode for UART0 TX   The original define is UART0, here we change it to UART2. It is strongly recommended to do so. Otherwise you’ll find that UART can’t work at all. Another comment here is PTE16 and PTE17 is conflict with SPI. You must disable SPI or change SPI function to other pins.   Next we must modify peripherals_KV31F512.h. const peripheral_descriptor_t g_peripherals[] = { #if BL_CONFIG_SCUART    // UART0    {.typeMask = kPeripheralType_UART,      .instance = 2, // change this value from 0 to 2      .pinmuxConfig = uart_pinmux_config,      .controlInterface = &g_scuartControlInterface,      .byteInterface = &g_scuartByteInterface,      .packetInterface = &g_framingPacketInterface },   Although there is a baud rate definition TERMINAL_BAUD, but it is never used too. MCU bootloader2.0.0 use auto baud rate detection. When power on, bootloader will go to autobaud detection mode. KinetisFlashTool sends ‘0x ’ every second. Bootloader check this byte and calculate baud rate.   After getting this value, bootloader will change to normal communication mode. Baud rate will not change until reset. If blhost is used, subsequent blhost invocations must specify the same baud rate as was used for the initial invocation unless the bootloader is reset. If the baud rate is not specified using the -p COMx, <baudrate> option, the UART baud rate will be set to 57600. Since Kinetis MCU UART module don’t have auto frequency detect function, the bootloader detects frequcny by software. It uses GPIO interrupt and timer to measure frequency. But in bootloader, there is only code for UART0, there isn’t code for other UART port. We must add the code. In hardware_init_KV31F512.c, modify the function get_uart_clock()   uint32_t get_uart_clock(uint32_t instance) {    switch (instance)    {        case 0:        case 1:            // UART0 and UART1 always use the system clock            return SystemCoreClock;        case 2:            return get_bus_clock();        default:            return 0;    } }   KV31 has 4 UART, include three UART modules and one low-power UART. They have different clock source. UART0 and UART1 use System clock while UART2 and LPUART0 use Bus clock. Thus, we finished the work. UART2 can work as the download port now.
View full article
First let us see the clock tree: Core clock up to 112M, Bus clock up to 56M, Flash clock up to 28M. Clock can been from: System OSC、Slow IRC 、Fast IRC and System PLL 1. OSC SCG_SOSCCFG 2. PLL configuration formula: SPLL_CLK = (VCO_CLK)/2 VCO_CLK = SOSC_CLK/(PREDIV + 1) *(MULT + 16)  3. SCG_SPLLCSR void SystemClockInit(void) { SCG->SOSCCFG = 0x3C; SCG->SOSCCSR |= 1<<0; /* SOSCEN=1 enable SOSC clock */ /*wait clock active*/ while((SCG->SOSCCSR & SCG_SOSCCSR_SOSCVLD_MASK) == 0); SCG->SPLLCSR &= ~(0x1<<0) ; /* SPLLEN=0: disable PLL*/ SCG->SPLLCFG &= ~(0x7<<8); /* PREDIV=0: 1 */ SCG->SPLLCFG |= 0xCU<<16; /* MULT=12: 28   PLL VCO = 8/1*(12+16) = 224M */ SCG->SPLLCSR |= 0x1<<0; /* SPLLEN=1: enable PLL */ /* wait PLL active*/ while((SCG->SPLLCSR & SCG_SPLLCSR_SPLLVLD_MASK) == 0); SCG->RCCR |= SCG_RCCR_DIVCORE(0); /* DIVCORE=0: 1, CORE/SYS_CLK  112MHz */ SCG->RCCR |= SCG_RCCR_DIVBUS(1); /* DIVBUS=1: 2, BUS_CLK  56MHz */ SCG->RCCR |= SCG_RCCR_DIVSLOW(3); /* DIVSLOW=2: 4   FLASH_CLK  is 28MHz */ SCG->RCCR &= 0xFEFFFFFF; /* Initially set to SIRC so that LSB could be set as '0' */ SCG->RCCR |= SCG_RCCR_SCS(6); /* SCS=6: system clock System PLL */ }
View full article
The AOI and Crossbar modules are inregrated in DSC, Kinetics KV and i.mxrt families, user can use them to generate complicated trigger signal for the on-chip peripherals. The DOC discusses the AOI function, crossbar fuction based on KV58. It gives the example, the example demos how to implement AND operation of two signals via crossbar switch A and B and AOI modules. The two logic signals are connected to the pads of KV58, and routed to AOI inputs via Crossbar switch B, the AOI sub-module0 implements the AND operation of the two signals, and output the AND output signal Event0  to pad of KV58 via crossbar switch A. Connect input pads and output pad of KV58 to oscilloscope, from the waveform of the three signals on scope, we can see that the AND logic  is implemented.
View full article
I’ve noticed some comments about Kinetis MCUs availability and status that I’d like to address for the entire community. The Kinetis MCU portfolio has seen significant growth in the mass market and is on track for continued strong growth in the coming years. Due to this growth, the demand on the Kinetis MCUs has outstripped the available supply, leading to extended leadtimes.  We have invested additional resources across the manufacturing line for 2018 and beyond to increase overall capacity and are pleased to be able to communicate that the lead time is being reduced from 39 weeks to low 30's this month.  It is anticipated there will be further reduction in Q3 2018 with a target of being back to a typical 12-14wk lead time in Q1 2019.  Additionally, we have increased our product longevity commitment on Kinetis K, L, E, V, M and W MCUs to 15 years to support the strong pipeline of design-in activity across the Kinetis portfolio that we are seeing in the market.   This document was generated from the following discussion: Kinetis Availability &amp; Longevity
View full article
The board used: FRDM-KE02 SWD: The ARM Serial Wire Debug interface uses a single bidirectional data connection(SWDIO) and a separate clock (SWDCLK) to transfer data synchronously. An operation on the wire consists of two or three phases: Packet request       The external host debugger issues a request to the DP. The DP is the target of the request. Acknowledge response   The target sends an acknowledge response to the host. Data transfer phase First enter into SWD mode: Send at least 50 SWCLKTCK cycles with SWDIOTMS HIGH and 0xE79E. This ensures that the current interface is in its reset state and enable the SWD mode. uint8_t SWJ_JTAG2SWD(void) {     uint32_t i;     SWDIO_SET();     for(i = 0; i < 56; i++)     {         SW_CLOCK_CYCLE();     }     SWJ_SendData(0xE79E);//SWJ_SendData(0xB76D);以后遇到再加     for(i = 0; i < 56; i++)     {         SW_CLOCK_CYCLE();     }     SWDIO_CLR();     for(i = 0; i < 16; i++)     {         SW_CLOCK_CYCLE();     }     return 0; } Then write DP/AP register. A successful write operation is as below: DP Register: Address     Read              Write 0x00        IDCODE           ABORT 0x04        CTRL/STAT      CTRL/STAT 0x08        RESEND           SELECT 0x0C        RDBUFF           N/A Address     Read              Write 0x00         CSW               CSW 0x04         TAR               TAR 0x08         N/A                N/A 0x0C         DRW              DRW 0xFC         IDR                N/A Read IDCODE: uint8_t SWJ_ReadDP(uint8_t adr, uint32_t *val) {     uint32_t tmp_in;     uint8_t ack;     uint8_t err;     tmp_in = SWD_REG_DP | SWD_REG_R | SWD_REG_ADR(adr);     ack = SWD_Transfer(tmp_in, val);     (ack == DAP_TRANSFER_OK) ? (err = 0) : (err = 1);     return err; } uint8_t SWJ_ReadAP(uint32_t adr, uint32_t *val) {     uint8_t tmp_in, ack, err;     uint32_t apsel = adr & APSEL;     uint32_t bank_sel = adr & APBANKSEL;     if(SWJ_WriteDP(DP_SELECT, apsel | bank_sel))     {         return 1;     } tmp_in = SWD_REG_AP | SWD_REG_R | SWD_REG_ADR(adr);     /* first dummy read */     ack = SWD_Transfer(tmp_in, val);     ack = SWD_Transfer(tmp_in, val);     (ack == DAP_TRANSFER_OK) ? (err = 0) : (err = 1);     return err; }
View full article
How to byte program SPI flash via QSPI QSPI module are used in many Kinetis MCU, like K8x, K27/28 and KL8x. QSPI expands the internal flash range and can run in a fast speed. Compared to DSPI, QSPI is very complex and often takes a lot of time to learn. In KSDK there are two QSPI demo which shows how to program SPI flash in DMA mode and polling mode. Both of them program the QSPI flash with a word type array. But can the QSPI module program SPI Flash in byte? Yes, this article shows how to do it. Device: FRDM_KL82Z Tool: MCUXpresso IDE Debug firmware: JLINK I build the test project base on KL82 SDK/driver_example/qspi/polling_transfer. To byte program SPI flash, a new LUT item must be added. uint32_t lut[FSL_FEATURE_QSPI_LUT_DEPTH] =    { /* Seq0 : Quad Read */          /* CMD:       0xEB - Quad Read, Single pad */          /* ADDR:       0x18 - 24bit address, Quad pads */          /* DUMMY:     0x06 - 6 clock cyles , Quad pads */          /* READ:       0x80 - Read 128 bytes, Quad pads */        …        …        [32] = QSPI_LUT_SEQ(QSPI_CMD, QSPI_PAD_1, 0x02, QSPI_ADDR, QSPI_PAD_1, 0x18),        [13] = QSPI_LUT_SEQ(QSPI_WRITE, QSPI_PAD_1, 0x1, 0, 0, 0),        …        /* Match MISRA rule */        [63] = 0}; This item tells system how to program a single byte. Then when we write the data to TxBuffer, we must write the byte 4 times. This is because a write transaction on the flash with data size of less than 32 bits will lead to the removal of four data entry from Txbuffer. The valid bit will be used and the rest of the bits will be discard. Then before we start programming, we must set the data size.      QSPI_SetIPCommandSize(EXAMPLE_QSPI,1);   After byte program, we can see the result from 0x68000000. Attachment is the demo project. You can find that 0x03 was written to 0x68000005 after running.
View full article