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.

The TWR-KW2x board's OpenSDA is programmed with MSD (Mass Storage Device) application, that's why you see it listed as a disk drive. With that firmware, you can drag/drop .bin and .srec files to the board and that would flash it, but you won't be able to debug. For the boards to support download/debug features, the firmware for the OpenSDA had to be the Debug App ("DEBUG-APP_Pemicro_v108.SDA"). But PEMicro released a new firmware which supports BOTH functionality in the same firmware. You can also find it latest OpenSDA firmware at https://www.pemicro.com/opensda/ For example: Firmware that supports Debug and MSD functionality for TWR-KW24D512: "MSD-DEBUG-TWR-MKW24D512_Pemicro_v114.SDA". You can find attached the document with the instructions to modify the OpenSDA firmware on the TWR boards, basically you have to: 1. Unplug the board 2. Insert a Jumper in J30 to put the device in Bootloader mode 3. Plug in the board (Mini-USB) 4. Device will be enumerated as a "Drive Disk" But now with a "Bootloader" label 5. Drag and Drop the .SDA firmware to the drive (MSD-DEBUG-TWR-MKW24D512_Pemicro_v114.SDA) 6. Unplug the board 7. Remove Jumper 8. Plug in the board (Mini-USB) Now you should see the board being enumerated as "OpenSDA - CDC Serial Port" (allowing you to download/debug) and also listed as a disk drive(allowing you to drag/drop images to the board). Note1: If the "OpenSDA - CDC Serial Port" driver is not recognized, you can locate the driver within the TWR's Disk Drive (MSD) Note2: Jumper has to be in place in J29 for debugging Hope this info is helpful. You can find additional information on www.freescale.com/TWR-KW2x  --> Downloads -> Board Support Package  AND BeeKit Wireless Connectivity Toolkit

Hello Community fellows! This time I would like to thank BlackNight for giving us great material to work on. There have been several posts inquiring the uses of USB stack and Processor Expert. The examples he has worked on and now shares with all of us, include this and many more useful concepts that you'll find interesting with the use of boards. For this issue he turns his FRDM-KL25Z into a generic USB keyboard device. With a simple button press he is able to send any keyboard actions to his laptop, making such as ‘print screen’ a single button press...isn't that amazing? :smileygrin: Well, I'll say no more, you better check it out yourself!  MCU on Eclipse by Erich Styger

One of the new features that can be found on the FRDM-K82F is the FlexIO header. It’s be specifically designed to interface with the very cost-efficient OV7670 camera, and uses 8 FlexIO lines to read data from the camera. By using the FlexIO feature, it makes it easy to connect a camera to a Kinetis MCU. A demo is included with Kinetis SDK 1.3 which streams the video data from the camera to a host computer over USB. FlexIO: The FlexIO is a highly configurable module found on select Kinetis devices which provides a wide range of functionality including: • Emulation of a variety of serial/parallel communication protocols • Flexible 16-bit timers with support for a variety of trigger, reset, enable and disable conditions • Programmable logic blocks allowing the implementation of digital logic functions on-chip and configurable interaction of internal and external modules • Programmable state machine for offloading basic system control functions from CPU All with less overhead than software bit-banging, while allowing for more flexibility than dedicated IP. Running the Demo: First you’ll need to setup the hardware. An 18 pin header needs to be installed on the *back* of the board. The camera is oriented this way to allow for use of shields on the top, even if the camera is being used. This way the functionality could be extended with WiFi or LCD shields. After the header is soldered on, plug in the camera. It will look like the following when complete: Next we need to program the K82 device with the example firmware. The software can be found in the Kinetis SDK FRDM-K82F stand-alone release, in the C:\Freescale\KSDK_1.3.0_K82\examples\frdmk82f\demo_apps\usb\device\video\flexio_ov7670 folder. Open the project, compile, and program the example specific for your compiler like done for other examples. Make sure you also compile the USB Device library as well. After programming the K82, unplug the USB cable from J5 (OpenSDA) and plug it into J11 (K82 USB). The board will enumerate as a generic USB video device called “USB VIDEO DEMO”. You can then use this device with any video capture software, like Skype or Lync.  Here's a shot of the clock in my cube: The resolution is 160*120, the video image format is RGB565. You may need to manually adjust the focus by rotating the lens on the camera. The frame rate can also be sped up by modifying line 342 in usb_descriptor.c: 5fps: 0x80,0x84,0x1E,0x00, /* Default frame interval is 5fps */ 10fps:  0x40,0x42,0x0F,0x00, 15fps:  0x2A,0x2C,0x0A,0x00, 20fps:  0x20,0xA1,0x07,0x00, The 160*120 max resolution was determined by the amount internal SRAM of the device, as there is not external RAM on the FRDM-K82F board. More Information: One of many places to buy the OV7670 camera module​ OV7670 Reference Manual​ FlexIO Overview ​ FlexIO Training presented at FTF

1. Kinetis L系列将NMI和Reset管脚复用成GPIO需要注意的问题 2. 如何在IAR、Keil和Codewarrior中禁止掉Kinetis的NMI脚 3. Kinetis Reset管脚与外部看门狗/复位芯片接法 4. Kinetis L系列外部IO中断分配问题 5. KL2x/KL4x使用USB模块时需要注意VOUT33管脚的接法 6. Kinetis K系列SPI接口设计注意事项 7. Kinetis芯片Reset管脚出现方波的原因及解决办法

Hello Kinetis friends! The launch of new Kinetis devices and development tools called "Kinetis K2" brought some new K22_120 MHz devices to the K22 family portfolio. :smileyinfo: Please notice the name "Kinetis K2" only refers to the Kinetis generation, but it is not related to part number (e.g. K63/K64 are part of K2 generation). Previously existing Kinetis portfolio already had some K22_120 MHz devices, so this  caused confusion regarding the documentation, header files, features, development boards and others, because the part numbers are very similar. I created the next reference table outlining the existing K22_120 MHz parts with their corresponding files and boards. The last column is an overview of the features or peripherals that are either missing or added in each device. :smileyalert: IMPORTANT NOTES:           - I gathered and put together this information as reference, but it is not official. For the most accurate information please visit our webpage www.nxp.com.           - Header files MK22F12.h and MK22FA12.h apply for legacy K22_120 devices. However TWR-K21F120M(A) board has a K21_120 part, so use MK21F12.h or MK21FA12.h instead.      Colleague Carlos Chavez released an Engineering Bulletin (EB811) with good information related to this document:      http://cache.nxp.com/files/microcontrollers/doc/eng_bulletin/EB811.pdf Regards! Jorge Gonzalez

作者 Sam Wang & River Liang    说明,本文对比8位MCU的位操作在系统升级到M0+内核的MCU后所带来的影响,可以作为客户对升级MCU时,对代码及RAM上资源的评估使用. 一)简单的I/O翻转对比.对比条件:MCU为MC9S08PT与KE02,开发平台CW10.3                   1.使用PT的代码如下:          if (!PORT_PTAD_PTAD0){             PORT_PTAD_PTAD0=1;         }else{             PORT_PTAD_PTAD0=0;}       PT的代码编译后占用9个Byte。                000002D4 000004   BRSET  0,PORT_PTAD,PORT_PTAD                000002D7 1000     BSET   0,PORT_PTAD                000002D9 202E     BRA    *+48       ;abs = 0x0309                000002DB 1100     BCLR   0,PORT_PTAD       2.KE是基于ARM的M0+内核，使用的代码如下                  if(GPIOA_PDOR & 0x1)                     { GPIOA_PCOR = 0x1;}                  else                     { GPIOA_PSOR = 0X1;}       编译后结果为                00000706:   ldr r3,[pc,#24]                00000708:   ldr r2,[r3,#0]                0000070a:   movs r3,#1                0000070c:   ands r3,r2                0000070e:   beq main+0x6c (0x718)       ; 0x00000718                00000710:   ldr r3,[pc,#12]                00000712:   movs r2,#1                00000714:   str r2,[r3,#8]                00000716:   b main+0x20 (0x6cc)       ; 0x000006cc                00000718:   ldr r3,[pc,#4]                0000071a:   movs r2,#1                0000071c:   str r2,[r3,#4]       这段M0+内核的代码编译后占用24个Byte       3.KE系列是Freescale在M0+的基础上加入了位操作引擎BME，用以优化ARM内核的位操作性能，使用BME功能的代码如下                     #define PTA0_SET   (void) (*((volatile unsigned char *)(0x4C000000+(0<<21)+0xF004))) //?==0                                                       //LAS1      第0位       GPIOA_PSOR地址的A0-A19                     #define PTA0_CLR   (void)(*((volatile unsigned char *)(0x4C000000+(0<<21)+0xFF008)))                                                      //LAS1      第0位       GPIOA_PCOR地址的A0-A19                     #define PTA0                *((volatile unsigned char *)(0x50000000+(0<<23)+(0<<19)+0xF000))                                                     //UBFX           第0位     1位           GPIOA_PDOR 地址的A0-A18                if (!(PTA0))                     {PTA0_SET; }                else                     {PTA0_CLR;}           KE的BME代码编译结果如下：                    165                if (!(PTA0)){                 00000998:   ldr r3,[pc,#24]                0000099a:   ldrb r3,[r3,#0]                0000099c:   uxtb r3,r3                0000099e:   cmp r3,#0                000009a0:   bne RTC_IRQHandler+0x18 (0x9a8); 0x000009a8                  166                PTA0_SET;                                             //Using BME                000009a2:   ldr r3,[pc,#20]                000009a4:   ldrb r3,[r3,#0]                000009a6:   b RTC_IRQHandler+0x1c (0x9ac); 0x000009ac                  168                PTA0_CLR;      //Using FASTER GPIO                000009a8:   ldr r3,[pc,#16]                000009aa:   ldrb r3,[r3,#0]       代码编译后占用20个Byte         4, CW里面有设置可以优化C编译器，具体路径在Project->Proteries->C/C++ Build->Setting->GCC C Complier->Optimization           优化后共用16个Byte                  165         if (!(PTA0)){                 0000091e:   ldr r3,[pc,#20]                00000920:   ldrb r3,[r3,#0]                00000922:   cmp r3,#0                00000924:   bne RTC_IRQHandler+0x12 (0x92a); 0x0000092a                  166                         PTA0_SET;                                             //Using BME                00000926:   ldr r3,[pc,#16]                00000928:   b RTC_IRQHandler+0x12 (0x92c); 0x0000092c                  168                         PTA0_CLR;      //Using FASTER GPIO                0000092a:   ldr r3,[pc,#16]                0000092c:   ldrb r3,[r3,#0]       5, 结果     如果单纯靠M0+内核访问寄存器，KE代码的占用空间与PT的比为24：9        如果使用KE的BME功能，代码与PT的比为16:9（使用了BME）        在判断Bit时, KE使用代码与PT的比为8:3        单单设置一个Bit时KE与PT代码占比为4:2 因此在M0+等ARM核上进行位操作，其效率比8位单片机低，使用了BME功能后，可以有效提高位操作的性能。 二)典型变量的位操作. 对比条件:MCU为MC9S08PT与KE02,开发平台CW10.3                测试代码:if (xx&1){              xx&=0xFE;       }else{             xx|=1;}       1,设置XX在0 page时,其与上面的I/O翻转结果一样,代码为9个BYTES    2,在KE中，编译结果如下,设置优化前,需要52个Bytes的代码量,26个执行周期.                                                     if (xx&1){                00000a52:   ldr r3,[pc,#64]                00000a54:   ldrb r3,[r3,#0]                00000a56:   uxtb r3,r3                00000a58:   mov r2,r3                00000a5a:   movs r3,#1                00000a5c:   ands r3,r2                00000a5e:   uxtb r3,r3                00000a60:   cmp r3,#0                00000a62:   beq main+0x5a (0xa76)       ; 0x00000a76                     200                         xx&=0xFe;                00000a64:   ldr r3,[pc,#44]                00000a66:   ldrb r3,[r3,#0]                00000a68:   uxtb r3,r3                00000a6a:   movs r2,#1                00000a6c:   bics r3,r2                00000a6e:   uxtb r2,r3                00000a70:   ldr r3,[pc,#32]                00000a72:   strb r2,[r3,#0]                     203         }}                00000a74:   b main+0x28 (0xa44)       ; 0x00000a44                     202                         xx|=1;                00000a76:   ldr r3,[pc,#28]                00000a78:   ldrb r3,[r3,#0]                00000a7a:   uxtb r3,r3                00000a7c:   movs r2,#1                00000a7e:   orrs r3,r2                00000a80:   uxtb r2,r3                00000a82:   ldr r3,[pc,#16]                00000a84:   strb r2,[r3,#0]                     203         }}       3, 设置优化后,需要22/20个Bytes的代码量,11/10个执行周期.                ldr r3,[pc,#40]                     199         if (xx&1){                0000095e:   movs r2,#1                     197         xx++;                00000960:   ldrb r1,[r3,#0]                00000962:   adds r1,#1                00000964:   uxtb r1,r1                00000966:   strb r1,[r3,#0]                     199         if (xx&1){                00000968:   ldrb r1,[r3,#0]                0000096a:   tst r1,r2                0000096c:   beq main+0x34 (0x974)       ; 0x00000974                     200                         xx&=0xFe;                0000096e:   ldrb r1,[r3,#0]                00000970:   bics r1,r2                00000972:   b main+0x34 (0x978)       ; 0x00000978                     202                         xx|=1;                00000974:   ldrb r1,[r3,#0]                00000976:   orrs r1,r2                00000978:   strb r1,[r3,#0]                0000097a:   b main+0x20 (0x960)       ; 0x00000960 如果采用以空间换时间的话,其参考代码如下.                 if (xx==0){                                 xx=1;                 }else{                                 xx=0;  }       4, 如考虑中断嵌套的话,还令需要4个Byte代码。       5, 结果 KE使用代码与PT的比为至少为20:9。      在判断Bit时, KE使用代码与PT的比为8:3.       6,使用BYTE替换Bit, 编译结果,设置优化前,需要22个BYTES.                     197         if (xx==0){                000009e8:   ldr r3,[pc,#44]                000009ea:   ldrb r3,[r3,#0]                000009ec:   cmp r3,#0                000009ee:   bne main+0x38 (0x9f8)       ; 0x000009f8                     198                         xx=1;                000009f0:   ldr r3,[pc,#36]                000009f2:   movs r2,#1                000009f4:   strb r2,[r3,#0]                000009f6:   b main+0x3e (0x9fe)       ; 0x000009fe                     200                         xx=0;                000009f8:   ldr r3,[pc,#28]                000009fa:   movs r2,#0                000009fc:   strb r2,[r3,#0]    7,设置优化后,需要16/14个BYTES的代码量.                     197         xx++;                0000095c:   ldr r3,[pc,#36]                     202                         xx=1;                0000095e:   movs r1,#1                     197         xx++;                00000960:   ldrb r0,[r3,#0]                00000962:   adds r0,#1                00000964:   uxtb r0,r0                00000966:   strb r0,[r3,#0]                     199         if (xx){                00000968:   ldrb r0,[r3,#0]                0000096a:   cmp r0,#0                0000096c:   beq main+0x32 (0x972)       ; 0x00000972                     200                         xx=0;                0000096e:   strb r2,[r3,#0]                00000970:   b main+0x20 (0x960)       ; 0x00000960                     202                         xx=1;                00000972:   strb r1,[r3,#0]                00000974:   b main+0x20 (0x960)       ; 0x00000960       8, 结果 ,在RAM的空间允许的情况下,KE使用代码与PT的比为至少为12:9. 三) 8 bit变量加1       1,在PT中对8 bit变量加1,只需要4个BYTES.    24:                 XX++; 00000014 450000   LDHX   #XX       00000017 7C       INC    ,X       2,M0+的8 bit变量加1,设置优化前,需要14个BYTES                     197         xx++;                00000a44:   ldr r3,[pc,#48]                00000a46:   ldrb r3,[r3,#0]                00000a48:   uxtb r3,r3                00000a4a:   adds r3,#1                00000a4c:   uxtb r2,r3                00000a4e:   ldr r3,[pc,#40]                00000a50:   strb r2,[r3,#0]       3,而如果使用优化设置,那么要12个BYTES                     197         xx++;                0000095c:   ldr r3,[pc,#36]                     202                         xx=1;                0000095e:   movs r1,#1                     197         xx++;                00000960:   ldrb r0,[r3,#0]                00000962:   adds r0,#1                00000964:   uxtb r0,r0                00000966:   strb r0,[r3,#0]       4, 结果 , 在8 bit变量加1时,KE使用代码与PT的比为至少为12:4，但这是32bitARM内核操作8bit变量都普遍存在效率变低的现象。 四) 16位+8位加法       1, 8 bit 编译结果,需要8个BYTES.                0000008 320000    LDHX   xx                0000000B AF01     AIX    #1                0000000D 960000   STHX   xx       2, M0+ 编译结果,设置优化前,需要10个BYTES.                00000a44:   ldr r3,[pc,#44]                00000a46:   ldr r3,[r3,#0]                00000a48:   adds r2,r3,#1                00000a4a:   ldr r3,[pc,#40]                00000a4c:   str r2,[r3,#0].       3, M0+ 编译结果,设置优化后,需要8个BYTES.                0000095c:   ldr r3,[pc,#20]                0000095c:   ldr r3,[pc,#20]                0000095e:   ldr r2,[r3,#0]                00000960:   adds r2,#1                00000962:   str r2,[r3,#0]       4,结果,M0+在16位加法时能够达到8bit单片机的效率，结果相同. 五)结论     因此用户在移植PT(或其它8 bit MCU)代码到KE02时,要选型时需要充分考虑客户原先代码具体运算情况,理论上存在使用KE后代码变大的情况.   但是使用KE等32bitM0+内核时可以在16bit或以上的乘、加运算时获得更好的效率，占用更小的代码空间和运算时间。   另外KE对GPIO的控制寄存器比PT多了一些功能,可以一次操作多个I/O,是不错的功能.

Although most of us have a basic understanding of how an ADC works and how to understand some of the basic figures that define an ADC performance, that is far from really understanding how to fully interpret and use the figures depicted in a datasheet ADC section. With all those numbers it is easy to get lost on which ones to look at when we want to know how it will react to conditions such as frequency, signal amplitude, temperature, etc; having such knowledge would allow us to better fit a specific ADC to your application and take full advantage of its features. Having this in mind I took the time to compile some information related to what the most common figures that describe an ADC performance depicted in a datasheet mean, most of the material can be found in any Analog to Digital Conversion theory book; as I mentioned before this is just a general compilation of knowledge I hope will help you better understand those specifications. It assumes those of us who use datasheets are somehow familiar with the basic working of ADCs, so I will spare the basic concepts. Now down to business, this is a extract of a typical ADC section from a microcontroller's datasheet: I am almost certain not a lot of people who use microcontrollers, and more specifically ADCs; have a clear idea of what Total Unadjusted Error, Integral Non-Linearity or Differential Non-Linearity describe in the behavior of an ADC. Even though I will try to describe in detail the most common parameters I might miss some others and there is the possibility some of the information might not be as accurate as I would like it to be, if any of you reading this brief document have specific questions regarding any parameter I describe or miss by all means comment. Common ADC electrical characteristics depicted in datasheets EQ          Quantization error      Since the analog input to an ADC can take any value, but the digital output is quantized, there may be a difference of up to ½ Less Significant Bit between the actual analog input and the exact value of the digital output. This is known as the quantization error or quantization uncertainty as shown below. In ac (sampling) applications this quantization error gives rise to quantization noise. SINAD, SNR and ENOB (Signal to Noise plus Distortion, SIgnal to Noise Ratio and Effective Number of Bits)      Signal-to-Noise-and Distortion (SINAD, or S/(N + D) is the ratio of the rms signal amplitude to the mean value of the root-sum square (rss) of all other spectral components, including harmonics, but excluding dc. SINAD is a good indication of the overall dynamic performance of an ADC      as a function of input frequency because it includes all components which make up noise (including thermal noise) and distortion. It is often plotted for various input amplitudes. SINAD is equal to THD + N if the bandwidth for the noise measurement is the same. SINAD is often converted      to effective-number-of-bits (ENOB) using the relationship for the theoretical SNR of an ideal N-bit ADC: SNR = 6.02N + 1.76 dB, the equation is solved for N, and the value of SINAD is substituted for SNR.      Effective number of bits (ENOB) is a measure of the dynamic performance of an analog to digital converter and its associated circuitry. The resolution of an ADC is specified by the number of bits used to represent the analog value, in principle giving 2 N signal levels for an N-bit signal. However, all real ADC circuits introduce noise and distortion. ENOB specifies the resolution of an ideal ADC circuit that would have the same resolution as the circuit under consideration. Often ENOB is calculated using the relationship for the theoretical SNR of an ideal N-bit ADC: SNR =      6.02N + 1.76 dB, the equation is solved for N, and the value of SINAD is substituted for SNR. SFDR      Spurious Free Dynamic Range     One of the most significant specification for an ADC used in a communications application is its spurious free dynamic range (SFDR). SFDR of an ADC is defined as the ratio of the rms signal amplitude to the rms value of the peak spurious spectral content measured over the bandwidth      of interest. SFDR is generally plotted as a function of signal amplitude and may be expressed relative to the signal amplitude (dBc) or the ADC full-scale (dBFS) as shown in Figure n. For a signal near full-scale, the peak spectral spur is generally determined by one of the first few harmonics of the fundamental. However, as the signal falls several dB below full-scale, other spurs generally occur which are not direct harmonics of the input signal. This is because of the differential nonlinearity of the ADC transfer function as discussed earlier. Therefore, SFDR      considers all sources of distortion, regardless of their origin. INL      Integral Non-Linearity     Integral nonlinearity (acronym INL) is the maximum deviation between the ideal output of an ADC and the actual output level (after offset and gain errors have been removed). The transfer function of an ADC should ideally be a line and the INL measurement depends on the ideal line selected. Two often used lines are the best fit line, which is the line that minimizes the INL result and the endpoint line which is a line that passes through the points on the transfer function corresponding to the lowest and highest input code. In all cases, the INL is the maximum distance between the ideal line selected and the actual transfer function. DNL        Differential Non-Linearity      Differnetial NonLinearity relates to the linearity of the code transitions of the converter. In the ideal case, a change of 1 LSB in digital code corresponds to a change of exactly 1 LSB of analog signal. In an ADC there should be exactly 1 LSB change of analog input to move from one           digital transition to the next. Differential linearity error is defined as the maximum amount of deviation of any quantum (or LSB change) in the entire transfer function from its ideal size of 1 LSB. Where the change in analog signal corresponding to 1 LSB digital change is more or less than 1 LSB, there is said to be a DNL error. The DNL error of a converter is normally defined as the maximum value of DNL to be found at any transition across the range of the converter. The following figure shows the non-ideal transfer functions for an ADC and shows the effects of the DNL error.      A common result of excess DNL in ADCs is missing codes resulting from DNL < –1 LSB. THD      Total Harmonic Distortion Total harmonic distortion (THD) is the ratio of the rms value of the fundamental signal to the mean value of the root-sum-square of its harmonics (generally, only the first 5 are significant). THD of an ADC is also generally specified with the input signal close to full-scale, the harmonics of the input signal can be distinguished from other distortion by their location in the frequency spectrum. The second and third harmonics are generally the only ones specified on a data sheet because they tend to be the largest. EFS     Full Scale Error Full-scale error can be defined as the difference between the actual value triggering the transition to full-scale and the ideal analog full-scale transition value. Full-scale error is equal to the offset error + gain error Offset error The transfer characteristics of both DACs and ADCs may be expressed as a straight line given by D = K + GA, where D is the digital code, A is the analog signal, and K and G are constants. In a unipolar converter, the ideal value of K is zero. The offset error is the amount by which the actual value of K differs from its ideal value. Gain error The gain error is the amount by which G differs from its ideal value, and is generally expressed as the percentage difference between the two, although it may be defined as the gain error contribution (in mV or LSB) to the total error at full-scale. TUE      Total Unadjusted Error This is the result of performing conversions without having calibrated the ADC, it is dominated by the uncalibrated gain and uncalibrated offset terms in the data sheet. Although most devices will be well within the data sheet limits, it should be noted that they are not centered around zero and full range of the incoming analog signal is not guaranteed. Therefore, an uncalibrated ADC will always show unknown levels of gain and offset error, thus reflecting the worst case of conversion error the module can provide.

This document was created in collaboration with Dragos Musoiu Trying to debug a hard fault on MKW24D512, ARM Cortex M4 based microcontroller, we did not find too much documentation on working with IMPRECISE hard faults.  We started our investigation from the post of Erich Styger Debugging Hard Faults on ARM Cortex-M. Based on this, we used Erich’s code to find the hard fault source, but it was impossible to find the instruction that caused the hard fault, because the executed instructions around the saved PC looked to be correct.  After, we checked the Hard Fault Status Register, from the System Control Block of the ARM Cortex M4 processor, we found the FORCED bit set. The ARM Cortex M4 documentation mentions that this bit indicates a forced hard fault, generated by escalation of a fault with configurable priority that cannot be handled, either because of priority or because it is disabled. When this bit is set to 1, the HardFault handler must read the other fault status registers to find the cause of the fault. We checked the other fault registers and we found, in the Configurable Fault Status Register (Bus Fault Status Register) from the System Control Block of the ARM Cortex M4 processor, the IMPRECISERR bit set. According to the ARM Cortex M4 documentation, if this bit is set a data bus error has occurred, but the return address in the stack frame is not related to the instruction that caused the error. When the processor sets this bit to 1, it does not write a fault address to the BFAR. So that explained why we did not find the instruction that caused the hard fault using Erich’s indications. Also, this is an asynchronous fault. Therefore, if it is detected when the priority of the current process is higher than the BusFault priority, the BusFault becomes pending and becomes active only when the processor returns from all higher priority processes. The Cortex M4 processors have a write buffer feature that when a write is carried out to a bufferable memory region, the processor can proceed to the next instruction before the transfer is completed. This is great for performance, but can cause some complexity in debugging imprecise bus faults. Studying better the documentation, we found in the ARM Cortex M4 Auxiliary Control Register the DISDEFWBUF bit that when set to 1, disables write buffer use during default memory map accesses. This causes all BusFaults to be precise BusFaults but decreases performance because any store to memory must complete before the processor can execute the next instruction. In this way the processor will not continue executing the next instruction until the write operation is completed, and so enabling this bit and using Erich’s code the saved PC pointed to the instruction which caused the hard fault. In other case, if the Bus Fault is triggered by an instruction executed in an interrupt handler, with higher priority than the BusFault handler, setting the DISDEFWBUF can be useful in the debugging process because the BFAR register value remains valid in case of precise error.

This document covers some of the more common questions about the new Kinetis K8x family. Any new specific issues or questions should be posted into it's own thread, and will be added to this document as appropriate. Kinetis K80 Basics What is the K8x family? It is a new Kinetis family of Cortex-M4F devices, running up to 150MHz, that include 256K of Flash and 256K of SRAM. It features FS USB, SDRAM, QuadSPI, SPI, I2C, LPUART, and much much more. How does the Kinetis K8x family differ from other Kinetis K families? The K8x family offers the same advantages and compatibility as other Kinetis K families, but also offers several new features not found on other Kinetis K families: QuadSPI Support Dual Voltage Domains (independent VDDIO domain down to 1.8V for QuadSPI or other interfaces) EMVSIM (Euro, MasterCard, Visa Serial Interface Module) FlexIO Additionally the K81 and K82 families offer the following new security modules: LTC (Low Power Trusted Cryptography) Encryption / Decryption algorithms in hardware (as opposed to using mmCAU s/w libs) OTFAD (On The Fly AES Decryption) Zero latency decryption when executing encrypted code from QuadSPI Secure RAM 2KB of Secure Session RAM Because of the addition of a second voltage domain and QuadSPI, there is no hardware pin compatibility with previous Kinetis derivatives. However there is significant module and enablement re-use, so if you’re familiar with other Kinetis devices, it will be easy to get started with the K80. Where can I find reference manuals, datasheets, and errata? These can be found on the K8x documentation pages. Detailed information on the K81 is under NDA, so please contact your NXP sales representative for those documents. What’s the difference between the different K8x devices? K80 is the base version, which includes QuadSPI controller, SDRAM controller, FS USB, and much more. K81 adds DryIce Tamper Detect and the LTC/OTFAD modules K82 adds just the LTC/OTFAD modules K80 and K82 families have the same pin out for their respective packages. The pinout for K81 is slightly different but can still be compatible. What boards are available to evaluate the K80 family? FRDM-K82F: A Freedom board with a 100LQFP K82 device. Also includes dual QuadSPI, touch pad, Arduino compatible footprint, and FlexIO header compatible with OV7670 camera. TWR-K80F150M: A Tower board with 121XFBGA K80 device. Includes dual QuadSPI, SDRAM, EVMSIM, SDCard holder, touch pads, and more. TWR-POS-K81: A Point of Sale reference design board in tower form factor. This board is only available via your NXP sales representative. The K8x MCU Family Hardware Tools selection guide has more details on board differences. What packages are available? The 100 LQFP and 121 XFBGA packages are lead packages available today. The 144 LQFP package and the WLCSP are part of the Package Your Way (PYW) program, and you should contact your NXP sales representative if interested in those packages. What is the difference between K8x and KL8x families? The KL8x family shares many of the same features as the K8x family. The biggest differences are that the KL8x family uses the Cortex-M0+ core (instead of Cortex-M4F), has a lower max clock speed, and has less internal Flash and RAM. It also reduces the instances of peripherals available, but still includes QuadSPI, FlexIO, LTC, and BootROM peripherals like on the K80. See the KL8x Fact Sheet for more details. KL8x devices will be available in the first quarter of 2016. Software/Tools Where can I find instructions and details on the hardware used to evaluate the K8x family? FRDM-K82F: http://nxp.com/frdm-k82f/startnow​ TWR-K80F150M: http://nxp.com/twr-k80f150m/startnow ​ Which version of Kinetis SDK supports the K8x family? Kinetis Software Development Kit (KSDK) support is split depending on the evaluation platform. For TWR-K80F150M, support can be found in the Kinetis SDK 1.3 Mainline Release. For FRDM-K82F, support can be found in the Kinetis SDK FRDM-K82F Stand-alone release. Note that the FRDM-K82 standalone release is truly standalone, and does not require the mainline release to be installed. How do I run the FRDM-K82F OV7670 camera demo? See this Community post: https://community.freescale.com/docs/DOC-329438 How can I use the micro SD card reader on the TWR-K80F150M? Because the SD card signals are shared with the QuadSPI signals, the SD card slot is not connected by default. See section 3.14 of the TWR-K80F150M User Guide for details on how to connect it, with the understanding that QuadSPI will not be available on the board while using SDHC. How do I use the SDRAM on the TWR-K80F150M? See section 3.9 of the TWR-K80F150M User Guide. Due to the layout of the board, the OpenSDA UART feature cannot be used while running the SDRAM as jumpers J6 and J8 need to be removed. QuadSPI What is QuadSPI Flash? Why should I use it? QuadSPI is a name for a popular type of serial NOR flash memory that is SPI compatible, but also allows for multiple data lines (up to 4 per device, or 8 if done in parallel) with bi-directional data for increased memory bandwidth. The QuadSPI controller on the K8x also allows for Execute-In-Place (XIP) mode so that code can be executed out of this external memory. QuadSPI memory can be used for either extra memory storage or for extra code space, or a combination of both. After initialization, it appears as a readable area of memory starting at 0x6800_0000 (as well as at the alias regions). How can I program the QuadSPI? There is an example application in Kinetis SDK that shows how to program the QuadSPI at C:\Freescale\KSDK_1.3.0\examples\twrk80f150m\driver_examples\qspi For programming an entire application, the ROM bootloader can be used. Details are in the K80 Bootloader Tools Package. The Kinetis Bootloader QuadSPI User's Guide that comes as part of that package describes all the steps needed to get up and running with QuadSPI. There is also an example Kinetis SDK application that runs out of QuadSPI at C:\Freescale\KSDK_1.3.0\examples\twrk80f150m\demo_apps\hello_world_qspi_alias What performance tips are there if doing QuadSPI XIP? A few key performance factors: Ensure both the data and instruction cache is enabled Use as many data lines as possible (4, or 8 if available in dual/octal modes) Use DDR mode Any critical code should be placed in Flash/RAM for fastest performance If using XIP, code should be executed out of the QuadSPI aliased address space which starts at 0x0400_0000. A more detailed app note is under development. How do I debug code located in QuadSPI? You must make use of the aliased QuadSPI address space at 0x0400_0000. There is an example of this in the hello_world_qspi_alias example in Kinetis SDK. Due to the architecture of the M4 core on Kinetis, breakpoints cannot be set in the 6800_0000 address space, which is why the alias address space is provided. What app notes are available for the QuadSPI? Because the QuadSPI module found on the K8x family has also been used on other NXP devices, there are some app notes available that can be useful for QuadSPI development. Note that some of the implementation details and features as described in the app notes will be different for K8x, so please use the K8x reference manual for full details. AN4186​ AN4512​ AN4777​ ROM Bootloader Where can I find more information on the bootloader that comes built into the silicon of the K8x family? Download the K80 Bootloader Tools package. If interested in QuadSPI, the Kinetis Bootloader QuadSPI User's Guide that comes as part of that package describes all the steps needed to get up and running with QuadSPI. The other information found on the Kinetis Bootloader website is also useful as this is what the ROM Bootloader is based off of. What interfaces does the ROM Bootloader support? The ROM Bootloader on the K8x family can interface via LPUART, I2C, SPI, or USB HID (via BLHost) to erase and program both the internal flash and/or QuadSPI flash. This is the same bootloader found on other Kinetis devices, but also includes some more advanced features to support QuadSPI. How can I enter bootloader mode? By default, when using a Kinetis SDK project, the bootloader is disabled and the code immediately jumps to the address in Flash pointed at location 0x4. By asserting the NMI pin at reset though, the part can be forced to enter bootloader mode. This is useful for programming the QuadSPI or interfacing with the bootloader in other ways. This feature is controlled via the FOPT[BOOTPIN_OPT] bit, which the Kinetis SDK code sets to '0' to enable the NMI pin to enter bootloader mode. The NMI button on each board is: FRDM-K82F: SW2 TWR-K80F150M: SW2 The FOPT register (at 0x40C) can be modified to always go into Bootloader mode if desired. Details are in boot chapter of the K80 reference manual. Where is the bootloader configuration data found in Kinetis SDK? The Bootloader Configuration Area (BCA), which begins at address 0x3C0, is defined in C:\Freescale\KSDK_1.3.0\platform\devices\MK80F25615\startup\system_MK80F25615.c starting on line 133. You must also add the define BOOTLOADER_CONFIG in the project settings to let the linker files know to program this BCA area. The FOPT configuration register (at 0x40D) is defined in C:\Freescale\KSDK_1.3.0_K82\platform\devices\MK82F25615\startup\<compiler>\startup_MK80F25615.s and by default is set to 0x3D which disables the bootloader, but does enable the option to enter bootloader via the NMI pin at reset (see previous question) How can I use the UART port on the FRDM-K82F with the BootROM? The OpenSDA/UART lines on the FRDM-K82F use LPUART4, which is not used by the BootROM. If you would like to use the serial UART lines to interact with the BootROM, you can blue wire a connection from either J24 or J1, and connect to R32 (RX) and R36 (TX). This was due to muxing trade-offs. The OpenSDA/UART lines on the TWR-K80F150M are connected to UART1 and thus no modification is necessary for that board. Also keep in mind that you can use the USB interface with the BLHost tool on both boards with no modification. The examples in Kinetis SDK setup the QuadSPI Configuration Block (QCB) data using a qspi_config.bin file. How can I generate my own custom QCB file? There is a C file that come as part of Kinetis SDK (C:\Freescale\KSDK_1.3.0\examples\twrk80f150m\demo_apps\hello_world_qspi\qspi_config_block_generator.c) or in the KBoot zip file, that can be compiled with various toolchains on a host computer, that will then produce a .bin file. You could import this file, and then after compilation, run it, and it will write out the new .bin to your hard drive. There is a tool under development that simplifies this process by reading in that example .bin file and then you can modify the fields in the app, and then it will write out the modified .bin file. Can I jump directly to QuadSPI for Execute in Place (XiP) after booting? Yes. However note that you must still put the Bootloader Configuration Area (BCA) into internal flash. And you also may want to put the QuadSPI Configuration Block (QCB) in flash as well since it needs to be read before the QuadSPI is setup. Thus even if all your code is in QuadSPI address space, the internal flash must also be written at least once to put in the configuration data. Once you have that set though, then you can develop code by only programming the QuadSPI address space. Troubleshooting I’m having debugger connection issues when using an external debugger, like a Segger JLink. Why? It’s likely that the OpenSDA circuit is interfering, and thus needs to be isolated via jumpers on the board. For TWR-K80F150M: Pull J16 and J17 For FRDM-K82F: Pull J6 and J7 Also make sure you are using the correct debug header for the K8x device on the board: For TWR-K80F150M: J11 For FRDM-K82F: J19 Where is the CMSIS-DAP/OpenOCD debug configuration for the K8x family in Kinetis Design Studio? KDS 3.0 does not support programming the K8x family via the CMSIS-DAP interface. You will need to change the OpenSDA app on the board to either J-Link or P&E as described in the K8x Getting Started guides (Part 3). I can't get OpenSDA on the FRDM-K82F into bootloader mode. Make sure jumper J23 is on pins 1-2 to connect the reset signal to the OpenSDA circuit. On some early versions of the board this was incorrectly installed on pins 2-3 instead. When using IAR with the default CMSIS-DAP debug interface, I sometimes get the error: “Fatal error: CPU did not power up” This is an issue in some older versions of IAR. Upgrade to at least version 7.40.5 which fixes this. When using KDS with the JLink interface with the FRDM-K82F board, I get an error. If you see the error "The selected device 'MK82FN256XXX15' is unknown to this version of the J-Link software." it's because the J-Link driver that comes with KDS 3.0.0 does not know about the K82 family. You can either select a MK80FN256XXX15 device (which is compatible with the K82 on the board) or update the JLink software by downloading and installing the latest JLink Software and documentation pack. At the end of the installation process it will ask to update the DLLs used by the IDEs installed on your computer, so make sure to check the KDS checkbox on that screen. I’m using the P&E OpenSDA App and debugging is not working. I get either "Error reading data from OpenSDA hardware. E17925" or “The system tried to join a drive to a directory on a joined drive” in KDS If using IAR, make sure you have the latest version (7.40.7 or later) If using KDS, you need to update the P&E plugin in KDS. Go to Help->Check for Updates, and select the P&E debug update. Make sure not to select the other debugger updates as it will break it in KDS 3.0.0 (see this thread)

当芯片被加密后，在Keil或IAR中下载或者调试时，会弹出以下提示信息： 这时如果点击Yes,那么将会对Flash进行一次mass erase,这样就可以重新下载或者调试程序了。 如果把Do not show this message again复选框勾选上的话，那么以后将不再弹出此提示框，并且会自动进行一次mass erase。 实际使用中，不建议勾选Do not show this message again这一复选框，因为勾上之后就无法直观的看到芯片被锁的提示了。 如果不小心把这一复选框勾上了的话，想要恢复到原来的设置，只能通过修改注册表的方法来实现，具体步骤如下 1) 在CMD窗口下，输入regedit，打开注册表    2)设置 HKEY_CURRENT_USER => Software => SEGGER => J-Link => DontShowAgainUnlockKinetis 为0   

¡EL GRAN DÍA HA LLEGADO, PARTICIPA Y ELIGE AL MEJOR! Te esperamos en el Centro de Congresos del Tecnológico de Monterrey Campus Guadalajara, la exhibición de los proyectos estará disponible a partir de las 09:00 hrs. Se nombrará al ganador a las 13:00 hrs. En seguida de la premiación de The Freescale Cup. La votación se abrirá a las 9:00hrs. Y se cerrará a las 12:30hrs, se tomarán en cuenta solo las interacciones realizadas dentro de este horario. Vota y califica tu proyecto favorito, sigue 2 pasos: 1. VOTA Elige solo UNA de estas 2 opciones. Ingresa a tu cuenta Twitter Publica el hashtag del proyecto #KinetisChallenge Ingresa al Facebook de Freescale University Programs Encuentra la liga y contesta la encuesta, o si lo prefieres puedes hacerlo desde el siguiente acceso.: https://es.surveymonkey.com/s/JQY76J9 2. CALIFICA Califica cada uno de los proyectos de acuerdo a los criterios de selección. Ingresa a https://apps.facebook.com/ranktab/rt.php?l=1452 Califica cada proyecto con los 3 criterios. Observa la matriz de burbujas para ver la opinión de los participantes. Comparte tu calificación en tu muro. Se tomarán en cuenta la sumatoria de votos en Twitter y Survey Monkey; así como la calificación en RankTab. ¡LA ELECCIÓN ESTÁ EN TUS MANOS!

我们知道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板的时候有所考虑。

This file describes how to install KSDK, is easy and simple with images and descriptions step by step, so you wont have problems with the installation.

Este teclado interactivo, esta hecho para ayudar a discapacitados en su desarrollo motriz. El teclado contara con cuatro botones, los cuales tienen un led en la parte superior y un sensor piezoelectrico. El LED superior se enciende, avisando al paciente que debe presionar el boton. El boton al ser presionado, activa al sensor, el cual manda una señal a la tarjeta freedom y prende un LED verde si activo el boton indicado o rojo si se equivoco. Finalmente el resultado de los botones activa un servomotor.   Ficha técnica del proyecto, indicando una descripción breve de su funcionamiento y especificaciones técnicas. Requerimientos técnicos para la exhibición del demo, como conexiones para lap top o conexión de internet.   Ficha tecnica Teclado interactivo para discapacitados Descripcion Este teclado se controla con la computadora. Tiene 4 botones y cada uno tiene un LED en la parte superior. El terapeuta elije que LED prender y el paciente debe presionar el botón correspondiente. Si presiona el botón debido, se prendera un LED verde y girara un servomotor, si se presiona cualquiera de los otros botones, se encenderá un LED rojo y el servomotor no reaccionara. Especificaciones de construcción Construcción: madera, MDF. Microcontrolador: Tarjeta Freedom Servomotor (x1) Capacitores cerámicos: microfaradios (x4) Sensores Piezoelectricos (x4) Leds (x6) Resistencias: 10K (x10) Requerimientos tecnicos Conexión USB a una computadora con programa Realterm para la comunicación serial.           Video final Tapete interactivo video final - YouTube Original Attachment has been moved to: codigo-teclado.txt.zip

We always received a question as below: “Where can I find the Altium footprint for Kinetis device XYZ?” First you can download the CAD file from the link below: Kinetis Symbols, Footprints and Models|NXP    It need to download an Ultra Librarian tool and install it: On Kinetis Symbols, Footprints and Models|NXP  I search for my device: I select the device and download the BXL file: In the Ultra Librarian tool, I load that *.bxl file, select my CAD tool of choice (Eagle) and export it: After exporting, a report is shown with the information where the files are stored (the duplicated folders are strange?) and instructions how to import it into Eagle: Following these steps, I have now the footprint in Eagle : Summary Finally, I can get footprints from NXP for the Kinetis Devices. It requires downloading multiple files and a converter. But this is fine, as it offers flexible conversion to many different CAD and PCB Layout tools, including the popular Eagle and Altium.

This is a Processor Expert project created by CodeWarrior for MCUs v10.6 which implements the charge-discharge time of a RC circuit for measuring capacitance. The charge-discharge sequence is performed by TPM0 operating in PWM mode, while the time is measured by TPM1 operating in Input Capture mode. A 100K ohm series resistor is being used, and the result is expressed on nF. It is also using the LCDHTA component from Erich Styger for showing the measurements on a 16x2 LCD, connected to the FRDM-KL05Z through a proto shield. The project is attached, and the pictures shows the measurements of three different capacitors: 10nF, 47nF and 1uF.