Kinetis Microcontrollers Knowledge Base

cancel
Showing results for 
Search instead for 
Did you mean: 

Kinetis Microcontrollers Knowledge Base

Discussions

       上篇详细的介绍了加密锁定Kinetis的一种方法,本篇再接再厉,给大家再介绍一种加密方法(哎,这点家底都晒出来了)。当然实际上原理还是不变的,即还是通过修改0x400~0x40F地址段的内容来实现加密锁定,万变不离其宗,所谓殊途同归罢了,下面好戏登台:        既然实现security最终都是改写寄存器加载段flash地址的内容,那实际上修改flash内容的方式还是灵活多变的,方案一中提到的在中断向量表的最后添加flash配置信息只是其中一种,那还有哪些呢?还是不摆谱了,小心被拍砖,哈哈。不错,那就是通过在指定地址定义常量的方法,当然定义常量大家都会用到(有些应用譬如LCD显示的字模或者一些固定的查找表为节省RAM空间我们一般会选择定义const常量的方法将它们存放到flash空间中),但是指定地址的存放方式用的会少些(一般都是让编译器自动分配的),如果我们非要指定地址呢(哎,强迫症又开始了,呵呵),即将flash配置信息作为常量强制指定存放到0x400起始的地址,那岂不是跟方案一有了异曲同工之妙了,好吧,这样的话那就该“@”这位老兄上场了(咳咳,可不是给单片机发email啊,呵呵),相信很多人到此处就都明白了。下面我仍然以IAR环境下锁定K60为例,简单介绍下方案二的使用步骤: 1. 打开待加密工程中的main.c文件,在其中的main函数之前以添加如下图所示常量定义,即将FlashConfig数据组数据存放到“.flashConfig”段中,其中FlashConfig[11]即为0x40C地址: 2. 至于这个.flashConfig段属性是需要在与该工程匹配的IAR连接文件(.icf文件)中人为添加定义的,如下图所示,需要添加三个部分,然后保存: 3. 前两步完成之后,其实需要添加的部分就已经完成了,但是还有特别重要的两点需要注意,这里我加红注释一下,如下: (1)采用方案二的情况,需要确保vectors.c中中断向量表最后的16个字节没有被添加,即不能有4个CONIFG_x配置信息的,否则会出现编译错误,因为这就涉及到两者冲突的问题,也就是说在采用方案一的话就不能采用方案二,同理,采用方案二的话也不能采用方案一,总之两者不能同存; (2)还需要考虑编译器优化的问题,因为我们在.flashConfig段定义了常量,但是在代码程序里却没有使用它,这种情况下编译器会直接把这段常量优化掉,所以我们做的工作算是白做了,即使我们在IAR的优化等级中设置成low或者none都不行,因为人家编译器认死理儿,反正你也没有使用它,我就是怕它pass掉,这下子伤心了,呵呵。还好IAR给我们留了条后路,在options->Linker->Input选项卡中提供了Keep symbol功能,如下图,将FlashConfig添加进去即可强制编译不优化它,这样目的就达到了,呵呵,看来还是天无绝人之路啊有木有。 3. 编译通过,下载调试,程序下载之后同样会出现进入不到调试窗口的现象,这个是正常现象,因为这个时候芯片就已经被security了,这样就可以放心量产了,呵呵~       希望这两篇系列文章能对大家有所帮助,enjoy it~
View full article
       所谓“知识产权保护”,其实就是在产品量产之后防止其芯片内部代码通过外部调试器被有效读取出来的手段,毕竟现在来说硬件电路是比较容易被复制的,如果软件再不设防的话,在山寨技术如此发达的今天(用发达来形容貌似不是很过分吧,呵呵)这个产品估计很快就会被淘汰了。        因为最近有很多客户问到关于Kinetis的加密锁定问题,所以我觉着还是有必要对其细说说的。其实飞思卡尔对于知识产权保护方面还是做了很大的功夫的,而且使用起来也是比较方便的(这点很重要),具体可以参考Kinetis的Reference Manual中Security这一章,这里我就以在IAR环境下锁定K60为例介绍一下使用方法: 1. 首先简单介绍一下原理,即如果将K60置于Security状态(即锁定状态),则是不能通过Debug接口或者EzPort接口对芯片内部flash有任何操作的(CPU还是可以正常读写flash的,也就是说程序还是可以正常运行的,只不过是不能被外部非法读取了),当然“mass erase”命令除外(我们平时在Jlink Command窗口中敲入的unlock Kinetis命令就是触发这个命令给芯片的),通过“mass erase”命令可以再次将芯片擦除到出厂状态(即unsecure解锁的过程),这样芯片就又可以正常使用了(方便用户之后的程序升级)。咳咳,不过不用担心,解锁之后的芯片其内部的flash已经被完全擦除掉变为空片状态,也就是说内部的代码已经没有了,所以。。。懂的。。。呵呵; 2. 说完Security的原理,下面再聊聊K60实现security的process。我们可以通过K60的FTFL_FSEC寄存器中的SEC位来设定芯片的security状态,如下图所示,芯片默认出厂状态SEC位是为10的,即非加密锁定的,而如果将SEC位设定为00、01或者11任何一种情况,则芯片都将处于锁定状态(这就是我们接下来要干的事了,呵呵)。这里可能会有人疑问,在这个寄存器在重新上电之后会保存内容吗,我只能说“咳咳,都能抢答了”,哈哈,这正是我下面要说的; 3. K60在flash中0x00000400~0x0000040F这16个字节范围的地址定义为寄存器加载地址(Flash配置区),如下图所示,而这其中0x0000040C的地址内容在芯片上电之后会被自动加载到FTFT_FSEC寄存器中,也就是说我们只需要在烧写程序的时候把相应数据写到该flash地址即可在上电之后对芯片进行加密锁定,由此实现加密锁定。 4. 好了,原理和process都说完了,准备工作就做好了,下面就撸胳膊抹袖子开工干活吧,呵呵。其实飞思卡尔已经为我们做好了相关工作,只不过我们平时因为用不到没有注意到罢了。我们打开IAR环境,然后导入需要加密的代码工程,再打开工程目录下cpu文件组中的vectors.c和vectors.h(如果你的工程架构类似于飞思卡尔官方的sample code的话就在这个路径下)。在vectors.h里的最后部分我们会看到4个config段(共16个字节大小),如下图1,这四个段就是定义了上述0x400~0x40F的内容,其中CONFIG_4中最后的0xfe即为0x40C地址的内容(注意ARM处理器默认是little end模式的,所以0x40C在低地址),0xfe表明SEC位为10,即非加密状态,这样如果我把该0x40C地址的内容改成0xfc、0xfd或者0xff任意一个都可以实现对芯片的加密锁定。至于该四个配置段定义是如何映射到K60的flash区中的呢,去vectors.c文件中中断向量表vector_table[]的最后看看就知道了,如下图2; 5. 这里我们选择将CONFIG_4内容由原来的0xfffffffe改成0xfffffffd即可,然后保存编译通过之后,在查看其生成的s19文件中可以看到如下图所示,即0x40C地址的内容被修改成了0xfd,这样烧写文件就搞定了; 6. 当然到这一步实际上还没有完,其实在IAR的新版本之后(IAR6.6之后),其自带的flashloader默认是把0x400~0x40F这段保护起来的(防止误操作对芯片意外的security),即使如上面所述修改好相应内容,在烧写的过程中flashloader也不会对这段地址的内容做任何擦除和写入。为此还需要再额外对IAR的flashloader进行配置,具体步骤如下: (1)进入Options->Debugger->Download,选择如下: (2)点击“OK”,然后系统会提示保存该修改后的flashloader配置,建议把自己修改好的.board文件保存到自己的工程目录下,方便以后直接调用该flashloader。 7. 至此全部设置就搞定了,点击编译连接,然后下载,即可把加密后的代码烧写到芯片的flash里面去了。注意如果我们点击调试按钮的话,一旦程序烧进去之后调试器会自动复位芯片,此时加密状态位会被load到FTFT_FSEC[SEC]位中,芯片的调试端口就会被停掉,所以这时进入不到调试界面,而是弹出错误窗口,不用担心,因为此时程序已经正确烧到芯片中,我们重新插拔电源之后会看到程序已经正常执行,而此时的芯片已经处于加密状态。当然如果我们想再进入调试模式调试芯片的话,一种是通过Jlink Command窗口解锁,如下图1,另一种是再次点击调试按钮,会弹出解锁窗口,点击解锁即可,如下图2。 图1 图2
View full article
Foreword This document is a supplement and revision of AN4379 Freescale USB Mass Storage Device Bootloader written by dereksnell in 2011. The original version was programmed with CW for Flexis JM/ColdFire MCF522XX/Kinetis K60. It has not been updated for 2 years. In 2013, I selected FSL MKL25Z as my prefer platform for USB host/OTG application, because it has on chip OTG module, instead of regular device module in its competitors have. I can develop some USB host applications. IAR is selected among commercial compilers for KL2X and other MCU development, since IAR can offer 32KB limited edition for ARM. In order to make AN4379 work on my FRDM-KL25Z, it involves porting efforts between compilers (from CW to IAR EW) and hardware platforms (from K60 to KL25). Reused Sources I gave up the original release since I found FSL USB stack has been improved in many ways between v4.0.3/v4.1.1 and Derek's base. The MSD application from USB stack are reused as baseline. I also merge flash and serial port driver from AN2295 Serial bootloader, as well as some helper functions for debug purpose. The printf( ) sometimes is more helpful than debugger, since it can reveal information during full speed run time. However, don't print out too many characters, since it occupies many resources. Don't print message everywhere, use it only when necessary and remove them in your final release. Bootloader Project & Sources A working bootloader project should include following files and paths. X:\Freescale USB Stack v4.0.3\Source\Device\app\msd_bootloader X:\Freescale USB Stack v4.0.3\Source\Device\app\common X:\Freescale USB Stack v4.0.3\Source\Device\source\driver\kinetis X:\Freescale USB Stack v4.0.3\Source\Device\source\class\usb_msc*.* X:\Freescale USB Stack v4.0.3\Source\Device\source\common Since I have not touched any code in Device\source folder and it is part of USB stack. You can unzip them into a separate folder and merge them into your existing USB stack tree. Be careful, since I have changed some code in common folder. It is up to you to merge them with compare tool. And MSD bootloader and MSD user application indeed have differences in main( ). Open the attached project msd_bootloader_v10beta_20131029.zip in IAR EW, rebuild it and download into debugger. Then you can connect its user USB port to PC, the OS will prompts MSC device connecting and BOOTLOADER driver is shown later on. You can drag and drop , copy and paste or enter in command prompt to copy any user application S-record file into BOOTLOADER driver. If your application code is designed for MSD bootloader, it will run after reset. For what is designed for MSD bootloader, please check the following chapter. First Thing First The bootloader must have conditional jump to user application. The condition could be push button or timeout counter. As a result, the GPIO and timer must be initialized as first step. According to Cortex-M's nature, MCG should be initialized as well in some cases. However, I find multiple calls to MCG initialization routines may cause system hangs on it. The detail logic has not been recovered so far. But I would like to recommend to initial GPIO and LPTMR only, without touching too much on MCG pll_init( ). Default Operation The bootloader will check if PTA2 has been grounded after reset. It will drops to bootloader anyway if it is connected to ground. Otherwise, it will check 0x8000~0x8004 for SP/PC checking. If there is a valid user application, it will transfer control to user application. If not, bootloader will enumerate an MSD driver called BOOTLOADER. There is a file called READY.TXT inside the driver. Custom Bootloader The bootloader can be used directly, or you can custom it. That's why I still keep the revised bootloader as open source. You can rename the driver label, download and run, more firmware format like intel hex, use another ISP push button, resize the driver, add CDC for debug purpose, add driver inf file for custom driver installation, add bi-directional communication over file system, add more features. However, you must understand FAT16 and make modification by yourself. You have to help yourself. Demo User Application Project Another attachment FRDM_KL25ZDemo_freedom.srec is demo project from Kinetis L family release and its S19 file, linked with modified ICF link file. The starting address of an user application is heavily device dependent, which basically related to its 32bit flash protection registers. Since MKL25Z128VLK4 has 128KB flash memory, the minimal protected flash block is 128K/32=4KB. The existing MSD bootloader release is 22KB (0x597F). So 0x6000 could be the start address of an application. Considering potential integrated features and data storage in future releases, 0x8000 is recommended as application start address. General Purpose ICF files During my development with AN2295(Serial) / AN4370(DFU) / AN4379(MSC device) bootloaders, I prepared more linker file. The only differences are the starting addresses, aka relocated vector address, ranges from 0x4000 / 0x8000 / 0xA000. The attachment Pflash_128KB_0x8000.icf explains itself from its name You can easily find necessary modifications for your ICF files in AN2295/AN4370/AN4379 documets. We can put three versions of ICF file in your linker script folder for easy development. Unnecessary Flash Protection Bytes By inspecting the S-Record file, I found the flash protection bytes are still reserved in user applications. Furthermore, the area between 0x80C0 and 0x83FF is kept as 0xFF, blank bytes. The flash protection bytes from 0x8410 to 0x841F are unnecessary since these flash protection bytes are useless in a relocated flash address besides 0x410~0x41F. We can remove the definitions and free some flash memories for user code and EEPROM emulation. In order to free these bytes, we must search source file and icf file who might hold them. This topic has not been covered here. Debug Skills You can debug both bootloader as well as user application with FRDM-KL25Z. Amazing ! It is easy for debug bootloader, since it is a regular application. How to debug a relocated user application? You can download the firmware by bootloader. After bootloader transfers control to the user application, you have to debug it in disassembly Window. Or you can download the user firmware as a regular application in debugger. The debugger will stop at main( ) of user application. If you want to debug the code before running main. Simply add more breakpoint, press reset. The debugger will tell you if you want to stop running to main. Click "stop", you will be forwarded to the address of user PC points to. By using these skills, I found my bootloader pll_init( ) has some side-effects on user application's pll_init( ). The debugger is very helpful in debugging both bootloader and relocated user firmware. Compare to IAR's debugger, Eclipse's debug Window is a mess. It has not reset button at all. That is why I usually use IAR for development and port to GCC later on. More Features FSL bootloaders only offers a basic framework. The users will need more features in future development. I am preparing following features when I am available. License file Including SNR and installation, activation, authentication as well as user API. By this license program, the firmware developers can monetize their IPR investment. User files Support emulated file with on-chip flash memories, Including drivers, html and other files. It is a handy feature since the users can access the related driver easily. And these files can be read-only and virus-proof. This files can also be used as keys for access control and other security applications. ROM API Since bootloader can be used as part of user application, we can integrate some important ROM API, like authentication, serial communication, and any other algorithms. It is simple to implement, define a dedicated code section, and use KEEP directive avoid optimization by the compilers. Limitations I have changed some code during this release. Like bootloader_task.c .FlashConfig should be updated to protect 32KB or 24KB. The current figure 0xFFFFFFFE only protects one block, aka 4KB.  And it is heavily device dependent. (Please correct me if I am wrong) So maybe there are still a lot of bugs. Feel free to leave your comment. I only tested it with S-record file, you are free to test it with CW binary and raw binary files. Even the S-record file, I have not tested those files with memory gaps in the file. Maybe you should padding the gaps with 0xFF before download.
View full article
    作者 Shaozhong Liang     YAFFS(Yet Another Flash File System)文件系统是专门针对NAND闪存设计的嵌入式文件系 统 。在 YAFFS中,文件是以固定大小的数据块进行存储的,块的大小可以是512字节、1024字节或者2048字节。这种实现依赖于它能够将一个数据块头和每个数据块关联起来。每个文件(包括目录)都有一个数据块头与之相对应,数据块头中保存了ECC(Error Correction Code)和文件系统的组织信息,用于错误检测和坏块处理 。     YAFFS在文件进行改写时总是先写入新的数据块,然后删除旧的数据块,这样即使意外掉电,丢失的也只是这一次修改数据的最小写入单位,从而实现了掉电保护,保证了数据完整性。 YAFFS是为NAND FLASH设计的,它作了以下的假设或定义。     NAND Flash是基于块(block)的,每一个Block大小相同,由整数个chunk组成。每一个Block可单独擦除。一页(page,或chunk)为Flash的分配单元。所有的访问(读或者写)都是基于页(或chunk)的。     当对NAND Flash编程时,只有二进制中的0被编程,而1则“不关心”。比如,一个字节包含的二进制数为1010,那么当编程1001,会导致这两个数的位与操作。结果为1000.这和NOR FLASH不同。     YAFFS 分别用块号和 chunk id 标示块和 chunk 。它将空块(填满0xFF)当作空闲块或者已擦除块。这样,格式化一个YAFFS分区等价于擦除所有未损坏的块。 因此YAFFS最少需要一些函数能够擦除块,读一个页,写一个页。 1. 直接接口 (Direct Interface)的相关文件     仅需要提取少量文件。使用yaffs的直接接口,你不需要所有的文件。你实际需要的文件列在下面,其余文件不需要编译。 direct/yaffsfs.c yaffs_guts.c direct/yaffscfg.c yaffs_nand.c yaffs_tagsvalidity.c yaffs_checkptrw.c yaffs_qsort.c yaffs_tagscompat.c yaffs_ecc.c yaffs_packedtags2.c 2. YAFFS   存储 设备     YAFFS 对文件系统上的所有内容(比如正常文件,目录,链接,设备文件等等)都统一当作文件来处理,每个文件都有一个页面专门存放文件头,文件头保存了文件的模式、所有者 id 、组 id 、长度、文件名、 Parent Object ID 等信息。因为需要在一页内放下这些内容,所以对文件名的长度,符号链接对象的路径名等长度都有限制。前面说到对于 NAND FLASH 上的每一页数据,都有额外的空间用来存储附加信息,通常 NAND 驱动只使用了这些空间的一部分, YAFFS 正是利用了这部分空间中剩余的部分来存储文件系统相关的内容。以 512+16B 为一个 PAGE 的 NAND FLASH 芯片为例 ,Yaffs 文件系统数据的存储布局如下所示: 0 to 511 数据区域 512 to 515 YAFFS TAG 516 Data status byte 517 Block status byte 坏块标志位 518 to 519 YAFFS TAG 520 to 522 后 256 字节数据的 ECC 校验结果 523 to 524 YAFFS TAG 525 to 527 前 256 字节数据的 ECC 校验结果     可以看到在这里 YAFFS 一共使用了 8 个 BYTE 用来存放文件系统相关的信息( yaffs_Tags )。这 8 个 Byte 的具体使用情况按顺序如下: Bits Content 20 ChunkID ,该 page 在一个文件内的索引号,所以文件大小被限制在 2^20 PAGE 即 512Mb 2 2 bits serial number 10 ByteCount 该 page 内的有效字节数 18 ObjectID 对象 ID 号,用来唯一标示一个文件 12 Ecc, Yaffs_Tags 本身的 ECC 校验和 2 Unused     其中 Serial Number 在文件系统创建时都为 0 ,以后每次写具有同一 ObjectID 和 ChunkID 的 page 的时候都加一,因为 YAFFS 在更新一个 PAGE 的时候总是在一个新的物理 Page 上写入数据 ,再将原先的物理 Page 删除,所以该 serial number 可以在断电等特殊情况下,当新的 page 已经写入但老的 page 还没有被删除的时候用来识别正确的 Page ,保证数据的正确性。 ObjectID 号为 18bit ,所以文件的总数限制在 256K 即 26 万个左右。     由于文件系统的基本组织信息保存在页面的备份空间中,因此,在文件系统加载时只需要扫描各个页面的备份空间,即可建立起整个文件系统的结构,而不需要像 JFFS1/2 那样扫描整个介质,从而大大加快了文件系统的加载速度。     一个 YAFFS 设备是一个逻辑设备,它代表了一个物理设备的部分或整体。你可以认为它是一个 Nand上的一个“ 分区 ” 。比如,该分区可能覆盖整个 NAND ,也许只是一半,而另外一半就是另一个 Yaffs_Device. 它也可以用于你使用一个非 flash 设备(比如 RAM )来测试的情况下。 一个 Yaffs_Device 记录了起始和结束块。通过改变它的起始和结束块,你就可以在同一个物理设备上使用不止一个的 Yaffs_Device 。 这里将需要你自己建立的 Yaffs_Device 结构的数据域列出,其他数据域由 Yaffs 自动创建。 int nDataBytesPerChunk     如其名,这是每一个 chunk 的字节数,还记得吧,在 yaffs 术语中,一个页就是一个 chunk ,因而它也是一页的字节数。它是数据字节数,即不包含 OOB 的数据。比如一页时 2048 字节 +64 字节的 OOB ,那么数值 nDataBytesPerChunk 为 2048。 int nChunksPerBlock     物理 Nand 设备中每页包含的 chunk (就是 Nand 上的页)的数目,最少是 2。 int spareBytesPerChunk     空闲域( spare area )大小,比如:每个 chunk (页)的 OOB 字节数。 int startBlock     该逻辑 Yaffs_Device 设备第一个块的块号(而字节地址),注意, yaffs 需要第一个块是空闲的,因此你不可以设置该变量为 0 ,如果设置为 0 , Yaffs 会给它加 1 ,并且会在结束块号上也加 1 ,在你设置设备从块 0 开始,到最后一个块结束,这意味着 yaffs 试图写一个不存在的块,从而出现错误。 int endBlock     该逻辑 Yaffs_Device 设备的最后一个块号。如果 startBlock 为 0 ,那么 yaffs 会使用 endBlock+1 ,至少使 startBlock+nReservedBlocks+2 int nReservedBlocks     这是 YAFFS 必须保留,用于垃圾回收和块错误恢复的可擦除块的数目。至少是 2 ,但是 5 更好。如果你使用一个不会损坏的介质,比如 RAM 或者 RAM 盘,或者主机文件系统模拟,那么可以是 2 。 int nShortOpCaches     配置当前设备 YAFFS Cache 项的数目。 0 值表示不使用 cache 。对于大多数系统,推荐使用 10 到 20 之间的一个数值。不能大于 YAFFS_MAX_SHORT_OP_CACHES 定义的数值。 int useNANDECC     这是一个标志,用于指示是由 yaffs 执行 ECC 计算,还是由 NAND 驱动程序来执行 ECC 计算。(译者注:此数值取 0 ,则使用 yaffs 来执行 ECC 计算,软件 ECC 计算。如果想要使用硬件 ECC 校验时,应该设置为 1 ,并且在 NAND 驱动程序中加入硬件 ECC 校验的代码。) void *genericDevice     这是一个指针,它应该指向任何数据,底层 NAND 驱动程序需要知道以从物理设备读、写。 int isYaffs2     我们使用的是否 YAFFS2版本 ? int inbandTags     是否为 OOB 区,如果不是,那么它为真,仅用于 yaffs2 u32 totalBytesPerChunk     这个名字可能有点误导人,它应该等于 nDataBytesPerChunk ,而非其名字暗示的 nDataBytesPerChunk + spareBytesPerChunk 。如果 inbandTags 为真,那么 yaffs 设置 nDataBytesPerChunk ,因此有足够的空闲空间存储数据, yaffs 会在空闲域中正常存储。 write/readChunkWithTagsFromNAND, markNANDBlockBad queryNANDBlock 这些都是函数指针,你需要提供这些函数来给 YAFFS ,读写 nand flash 。 3. NAND Flash 访问函数 int (*writeChunkWithTagsToNAND) (struct yaffs_DeviceStruct * dev, int chunkInNAND, const u8 * data, const yaffs_ExtendedTags * tags);   dev: 要写入的yaffs_Device逻辑设备. chunkInNAND: 将chunk写入的页 Data: 指向需要写入的数据的指针 tags: 未压缩(打包)的OOB数据 Return: YAFFS_OK / YAFFS_FAIL 该函数将页( chunk)写入nand 中, 向 nand中写入数据。数据和标签(tags)永远不应为 NULL. chunkInNand 是将要写入的页的页号,而不是需要转换的地址。 int (*readChunkWithTagsFromNAND) (struct yaffs_DeviceStruct * dev, int chunkInNAND, u8 * data, yaffs_ExtendedTags * tags);  dev: 要写入的 yaffs_Device 逻辑设备 . chunkInNAND: 将 chunk 读入的页 Data: 指向需要读入的数据的缓冲区指针 tags: 指向未压缩(打包)的 OOB 数据的缓冲区指针 Return: YAFFS_OK / YAFFS_FAIL 该函数执行上一个函数的相反的功能,首先,读取数据和 OOB字节,接着将这些输入放在一个由参数data指向的缓冲区 中 int (*markNANDBlockBad) (struct yaffs_DeviceStruct * dev, int blockNo);   dev: 要写入的yaffs_Device逻辑设备. blockNo: 要标记的块. Return: YAFFS_OK / YAFFS_FAIL int (*queryNANDBlock) (struct yaffs_DeviceStruct * dev, int blockNo, yaffs_BlockState * state, u32 *sequenceNumber);   dev: 要写入的 Yaffs_Device 逻辑设备 . blockNo: 要标记的块 . state: Upon returning this should be set to the relevant state of this particular block. Sequance number: 该块的顺序号( The Sequence number ),为 0 表示此块未使用 Return: YAFFS_OK / YAFFS_FAIL     它应检查一个块是否是有效的。如果在OOB中设置了坏块标记,那么*state应该被赋值为YAFFS_BLOCK_STATE_DEAD,*sequenceNumber赋值为0,然后返回YAFFS_FAIL。     如果该块没坏,那么应解压缩标签。标签解压缩后,若发现chunk已使用(查看tags.chunkUsed),则*sequenceNumber应赋值为tags.sequenceNumber,*state赋值为YAFFS_BLOCK_STATE_NEEDS_SCANNING,否则该块未使用,则*sequenceNumber赋值为0,*state赋值为YAFFS_BLOCK_STATE_EMPTY 4. YAFFS 的缓存机制     由于 NandFlash 是有一定的读写次数的,所以在对一个文件进行操作的时候往往是先通过缓冲进行,对最后一次性写入 NandFlash ,这有效的减少了用户对 NandFlash 的频繁操作,延长了 NandFlash 的寿命。 下面大致说一下 YAFFS 的缓存机制: 4.1. 首先在 yaffs_mount 的时候会对 yaffs_dev 这个结构体进行注册,和缓冲部分相关的有: dev->nShortOpCaches// 这个变量决定了有多少个缓冲,因为缓冲会大量的占用堆栈的空间,所以在 yaffs 不建议缓冲的数量很大,即使你填一个很大的数,系统也不会超过 YAFFS_MAX_SHORT_OP_CACHES 的总数。 yaffs_ChunkCache *srCache;// 缓冲区的首地址, dev->srCache = YMALLOC( dev->nShortOpCaches * sizeof(yaffs_ChunkCache)); 下面介绍一下缓冲区这个结构体的组成: typedef struct { struct yaffs_ObjectStruct *object;// 一个缓冲区对应一个文件 int chunkId; int lastUse; // 通过 lastUse 来 int dirty; // 标志了这一个缓冲区是否被使用 int nBytes; __u8 data[YAFFS_BYTES_PER_CHUNK];// 数据区 } yaffs_ChunkCache; 4.2. 什么时候用到缓冲区?         用到缓冲区最多的地方显而易见是对已经创建的文件进行写操作。而且是需要写的大小和 512 不一致的时候,这是因为如果是刚好 512 的话,系统会直接写入 NandFlash 中。对于小于 512 的系统首先会调用 yaffs_FindChunkCache(in,chunk) 这个函数来判断 in 这个 object 是否在缓冲区中存在。如果存在会调用已有缓冲区进行操作。当然如果是第一次对一个 object 进行操作,肯定在缓冲区中是不存在对应它的空间的,因此系统会调用 yaffs_GrabChunkCache 函数为此次操作分配一个缓冲区。 5. 应用层接 口     YAFFS 为连接的应用程序提供了一组函数。大部分跟标准 C 库函数 , 如 open/close 一致,只是增加了 yaffs_ 前缀,如 yaffs_open. 这些函数定义在 direct/yaffsfs.h 中。     初始化 yaffs 来完成读写,你必须在每个你要使用的 yaffs 设备上调用 yaffs_mount 。比如 yaffs_mount(”/boot”) 。这可以在系统启动的时候执行,如果存在一个操作系统,那么程序需要考虑这点。在你完成使用的时候,你也需要调用 yaffs_umount 函数,这样 yaffs 就会将它需要状态写入磁盘。 如果读写文件的应用层接口已经存在,你可以根据相关的操作系统调用来封装相关的函数调用。 1 yaffs_mount( ) 功能说明:加载指定器件。 输入参数:path    要加载的器件。 输出参数:无。 返回值: 表明加载的状态。 调用的函数:yaffsfs_FindDevice( )、yaffs_GutsInitialise( )。 2 yaffs_open( ) 功能说明:按照指定方式打开文件。 输入参数:path    文件的绝对路径;           Oflag   打开的方式;           Mode    文件许可模式。 输出参数:无。 返回值:句柄。 调用的函数:yaffsfs_GetHandle( )、yaffsfs_FindDirectory( )、yaffs_MknodFile( )、yaffsfs_PutHandle( )、yaffs_ResizeFile( )、yaffsfs_FindObject( )。 3 yaffs_write( ) 功能说明:根据打开文件的句柄,从指定数组处读指定字节写入文件中。 输入参数:fd      要写入的文件的句柄;           Buf     要写入的数据的首地址;           Nbyte   要写入的字节数。 输出参数:无。 返回值: 写入了的字节数。 调用的函数:yaffs_WriteDataToFile( )、yaffsfs_GetHandlePointer( )、yaffsfs_GetHandleObject( ) 4 yaffs_read( ) 功能说明:根据打开文件的句柄,从文件中读出指定字节数据存入指定地址。 输入参数:fd       要读出的文件的句柄;           Buf      读出文件后要存入的数据的首地址;           Nbyte    要读出的字节数。 输出参数:无。 返回值: 读出了的字节数。 调用的函数:yaffs_ReadDataFromFile( )、yaffsfs_GetHandlePointer( ) 5 yaffs_close( ) 功能说明:关闭已经打开的文件句柄,yaffs 有缓冲机制,当调用yaffs_close()关闭文件之后能够保证将内容写入nandflash。 输入参数: fd    需要关闭的文件的句柄; 输出参数:无。 返回值:无。 6. YAFFS 在 MQX的应用案例     YAFFS提供了直接调用模式,可以方便移植到 none-OS或者light-weighted OS中。附件是将YAFFS移植到Freescale MQX实时操作系统的源代码和工程,可以在II型集中器的Demo Board上运行。     初步的测试表明YAFFS工作正常,能够完成创建目录,创建/删除文件,读/写文件操作等 。 YAFFS非常适合none-OS或者是light-weighted OS,使用YAFFS需要关注的是RAM的消耗,适合小量文件(<20)。 如果不想使用MQX默认的MFS(FAT32文件系统),YAFFS可以作为一个文件系统的备选方案。
View full article
The Technical University in Brasov (Romania) has set up a Medical Teaching lab featuring the Freescale Tower Kit K53 with Oximeter MED-SPO2 and 2 electrode system EKG MED-EKG. Find below the material associated to this lab led by Prof. Sorin-Aurel Moraru from the Faculty of Engineering. He can be contacted at smoraru@unitbv.ro The course is in Romanian and include an overview of the hardware and exercises
View full article
作者 Shaozhong Liang         MQX4.0支持长文件名(Long FileName),但不支持中文长文件名。在MQX创建长文件名的文件时,只是简单地将文件名对应的字符串由转换为UNICODE编码。         如果使用的是拉丁字母,其编码将会被补全为2个字节,前面一个字节为0x00,例如字符“A”的编码是0x0041,是0x00接上字符对应的ASCII码。这个编码方式在英文字符串上编解码不成问题。         但是中文的表示方式是以GB2312编码方式,用2个字节来表示一个中文字。         例如中文字“啊”,对应的GB2312码为0xB0A1,MQX会将这2个字节拆分为0xB0和0xA1,然后分别进行UNICODE编码,这时候“啊”的编码将是0x00B0,0x00A1,变成4个字节的UNICODE编码。         最终将导致错误乱码,“啊”因此会被译码显示成  °  和  ¡         而实际上“啊”在UNICODE编码为0x554A,为了MQX能够支持中文长文件名,此时我们需要对GB2312和UNICODE进行转换。         我们需要对MFS源代码进行修改。现在修改后的代码只支持创建文件,暂时不支持修改已经存在的中文长文件名文件。         将附件中的文件替换原有的文件,重新编译MFS库和应用程序即可。         按照这种方法修改后,对中文字对应的GB2312编码范围进行UNICODE的转换,处理后文件名将支持中文,同时也可以实现中英文文件名的混用。 mfs\source\generic\mfs_entry.c 修改了函数MFS_create_directory_entry mfs\source\generic\mfs_lfn.c 增加了长文件名保存函数MFS_lfn_save 增加了oem字符集到unicode字符集的转换函数MFS_oem2unicode,用户层的代码直接使用中文文件名,有转换函数转换为对应的UNICODE编码。 由于GB2312全集占用空间太大,用户可以将gb2unicode.c的字符集表oem2unicode_table中数据进行精简。 mfs\source\include\mfs_prv.h 增加了上述函数声明。 Original Attachment has been moved to: lfn_mfs.rar
View full article
Hi,All Our team have developed the K60's peripheral derives lib which is open source and open source firmware library. the The open source lib have these feature just as follow: 1\The setup code based on the CMSIS Standard; 2\The lib include most of peripherals of K60 such as ADC,DAC,DMA,CAN,FTM,LPTMR, ENET,FLASH,FLexBUS,GPIO,IIC,MCG,PDB,SPI,USB,TSI,UART,WDOG,SDHC,PIT,etc. 3\All of the peripheral initiate function are based on the a structure variable Struct format. 4\Add parts of Freescale USB Stack into the lib such as USB CDC and USB HID mouse. 5\We also develop relative example projects to demonstrate how to use the library for the peripheral. All of the project are created by the IAR for ARM Ver.6.4. The attach is the code. We divide the code into two parts. One part is driver lib, and another part is project. PS 1:All of the code comments are Chinese, p lease forgive. PS 2:All of drivers is on the \lib\LPLD\HW.      The K60 project need Unzip into the \porject\. PS 3:The code has many place that need update and improve. if you have any doubt and opinions,please contact us.support[AT]lpld.cn Best Regards Wang
View full article
My customer wanted to use K60 in his design but he only has the Keil IDE, so I helped to port some examples in KINETIS_SC for him as a starting point. The attachment is my porting work, which also includes a exe file to create new keil project. You may refer to "keil\build\uv4\make_new_project_keil.exe" for details. Hope that helps, B.R Kan
View full article
This manual explains how to create a project in CW and add components to Processor Expert. It also includes a couple of examples to print and get data with the printf and scanf functions from the stdio library by using Serial component (UART).
View full article
最近,有客户反映在IAR6.6 环境中,即便在程序中配置了Kinetis的加密字段“0x40C -0x40F”,但在实际程序运行中发现这些加密位并没有被真正的写进去。现根据Colleagues的分析,结合个人的理解总结如下,描述不清楚之处希望能提出宝贵意见。 原因:新版本的IAR 6.6 为了 防止用户在使用Kinetis过程中误操作导致芯片被锁死,默认将加密位 Disable 了, 在烧录 Flash 的时候设了最后一道闸门,将 0x40C -0x40F 的值统一成 0xFFFFFFFE ( 解密模式 ) 。 如果要完成加密, 可以修改其 Flash Loader配置。 证据:在C:\Program Files\IAR Systems\Embedded Workbench 6.5_2\arm\config\flashloader\Freescale文件夹中,查看FlashK60Dxxx128K.board文件可以看到如下描述,其中<args_doc>与</args_doc>可以理解为一些注释,需要按解决方法的步骤设置。 <args_doc>.....--enable_config_write - allow programming of 0x40C - 0x40F with user supplied data, in other case flashloader after erase of block 0 will write 0xFFFFFFFE (unsecure state).</args_doc> 解决方法: 1) 打开IAR的Options配置框, 选择Debuger的 Download 标签, 勾选如下图 所示的选项, 可以看到 此项目中对应的 .board 文件; 2) 点击 edit 按钮, 显示如下对话框,两处分别对应 着 包含不同Flash Memory的器件设备; 3) 对于不包含FlexNVM的器件, 选择 0x0-0xfffffff 对应的条目,然后选择 Edit; 4) 在下面的对话框中的 extra edit 项目中填写 “ --enable_config_write ” , 它意味着打开了 在烧录 Flash 的时候设置的最后一道闸门,使能了用户对加密字段“ 0x40C -0x40F” 的配置。 关于此参数选项含义,可以查看下面框中 parameters description 的描述。 5) 选择 OK , 回到上级对话框,如下图可以 看到“--enable_config_write”作为一个Extra Parameters显示出来; 6) 再次选择 OK, 回到上层对话框。 此处不用担心OK后修改的配置会替换Flash Loader中的默认配置,因为 系统 会 自动保存刚才的修改 到一个新的 board 文件, 并存储到当前工程的文件目录中; 7) 选择“ save ” , 保存; 8) 选择 "OK” , 然后开始下载。 9) 如果以后需要加密的时候, 可以使用新的 board 文件, 不需要加密的时候,选择使用 IAR 下面的 board 文件。      至此,完成整个配置过程。 关于在 J_flash 中选择使用加密: 1)在 Jflash 中选择 project settings; 2)在Project settings栏选择CPU标签,勾选Device选项,并点击Freescale MKL25Z128xxx4后面的方框; 3)在如下窗口Manufacturer中选择Freescale,找到对应的Device,选择带有" allow security"的选项,就可以支持加密了。否则即便在程序中Kinetis的加密字节设置了加密,代码也不会实     际的运行。
View full article
     我想“超频”这个词估计大家都不会陌生,很多玩计算机的都会尝试去把自己电脑的CPU超频玩一些高端大型游戏(咳咳,当然玩的high的时候别忘了小心你的主板别烧了),而对我们这些搞嵌入式的人们来说,估计就只能用这样的情怀去折磨MCU了(当然前提得是有PLL或者FLL的MCU)。      在超频之前 首先需要澄清几个概念,我们通常所说的主频一般是指内核时钟或者系统时钟(即core_clk或system_clk)。而对K60来说,其内部还有总线时钟(Bus_clk)、外部总线时钟(FlexBus_clk)、flash时钟(Flash_clk),而这几个时钟互相关联且每个都是有其频率限制的(如下图1所示),所以当我们要超频内核时钟的时候还不得不考虑其他时钟承受极限(姑且用这个词吧)。在我们用MCG模块内部的PLL将输入时钟超频到200MHz作为MCGOUTCLK输出的时候还需要一道关卡(如下图2),也就是说虽然这几个时钟属于同宗(都来自MCGOUTCLK),但是也可以通过不同的分频器(OUTDIV[1:4])约束不同的时钟范围,这里想起一个形象的例子。MCGOUTCLK就类似以前的官家大老爷,娶了四房姨太太(OUTDIV[1:4]),分别生了四个少爷(即core_clk、Bus_clk、FlexBus_clk和Flash_clk),每个少爷都是老爷的儿子,不过在家中地位却是由姨太太的排序决定的,其中大房的大少爷(core_clk)地位最高(频率范围最大),四房的小少爷(flash_clk)地位最低(频率范围最小),不过他们的地位最高也不会超过老爷(其他clk<=MCGOUTCLK),呵呵,有点意思~ 图1 图2      经过上面的分析之后,就可以开始着手超频了。经过验证,其实系统频率超不上去就是“小少爷”(flash_clk)拖了后腿,当我们将MCGOUTCLK超到200MHz的时候,OUTDIV1的分频可以设置为1分频,保证内核频率为200MHz,但却要同时保证其他几个时钟不要超过太多,尤其是Flash_clk的限制要严格(建议不要超过30MHz,小少爷有些“娇气”),因为flash_clk过高就代表取指令的频率过高,指令出错就会造成系统程序跑飞。     说到这里,可能有些人会质疑,把主频超的那么高,但取指令的速度上不去有个啥用,岂不是颇有些大马拉小车的感觉吗,其实不然,这里我说两点。一个是通过RAM调试或者将函数声明成RAM执行函数的时候是可以加快执行速度的,另一个就是当做一些数学运算的时候作用就很明显了,因为一般可能会单纯用到CPU内部的ALU和寄存器组,后者数据访问多一些(注意Cortex-M4是哈佛结构,数据与指令总线独立的),自然其运算速度就上去了,所以还是好处多多的。      当然飞思卡尔本身是不建议超频的,数据手册上给出的极限值都是在保证系统可靠性和稳定性的前提下测试出来的,再往上就不敢保证了(跟你的硬件电路设计能力有一定关系),正所谓“超频有风险,用时需谨慎啊”,呵呵,所以我们大多数的应用还是老老实实的按照“规矩”来吧。不过这里需要提的一点是,每家厂商一般会为超频留有余地(为了满足一些客户的超频需要,哎,不容易啊),至于这个余地是多少,不同的半导体厂商也会有不同的标准。对我来说, 记得那是2008年的第一场雪,比往年来的稍晚了些…(没收住,开始整词儿了,呵呵),那一年我第一次接触飞思卡尔的9S12 16位的单片机(MC9S12DG128,哎,搞过智能车的都懂的),额定主频是25MHz,我把它超到40MHz,后来又换成了MC9S12XS128,额定主频是40MHz,我又把它超到80MHz(有点超频强迫症了,呵呵),一直到如今的ARM K60,额定主频为100MHz(VLQ100),所以。。。咳咳。。。很自然的我就把它超到200MHz,再往上我就没有测试了,因为基本也用不到那么高的频率,还是要掌握好这个“度”的,想过把超频的瘾的可以试试看,呵呵~
View full article
最近搞了一个基于TWR-K20D50M的的USB MSD device bootloader, 可以打开文件夹CW中的K20D5下的.project来查看。 在原始的MSD的基础上移植了FAT过来。 其他IAR和Kinetis的其他chip没有测试,如果需要使用,一个是新增相关头文件,二是在bootloader.h中修改相应的MCU_K20D50M定义下的flash及ram配置
View full article
中文版本:     相信很多博友在调试ARM代码的时候,尤其是涉及到操作底层的时候,由于一些误操作常常会遇到Hard fault错误或者程序跑飞的情况,这些bug采用正常的方法是比较难定位的,往往需要我们逐行去排查测试,最后看的眼花缭乱,永远给人以苦逼程序员的印象,呵呵。此篇内容致力于节省广大程序员的精力,以崭新的一种方法角度或者说是手段来定位跟踪bug(仅限于支持Coresight技术的ARM处理器,本篇只讲针对M0+内核的),故冠之以“原创猛料”之称号,希望能名副其实,好了,闲话不多说,呵呵,开整……     ARM的Coresight技术估计大家有所耳闻(没听过的可以参考我之前的一篇介绍类文章 http://blog.chinaaet.com/detail/29770.html ),它实际上包括了ARM嵌入到其处理器内核的片上跟踪调试组件和相关的配套系统软件标准之类的,方便我们开发调试ARM产品。可能单说Coresight技术有点太泛了,把它具体化的话就不得不提到ETB(Embeded Trace Buffer)和MTB(Micro Trace Buffer)这两个经典的模块,其中ETB模块是Cortex-M3/M4内核的片上跟踪单元,而MTB模块则是Cortex-M0/M0+内核的跟踪单元。 不过估计很多人没有用过,所以我就本着“吃螃蟹”的态度去尝试了一番,结果还是挺让我惊喜的,灰常好用,所以下面我就把使用方法分享给大家供大家评估,本文以MTB模块调试飞思卡尔基于Cortex-M0+内核的Kinetis L系列为例:     在介绍使用方法之前需要提一下,目前我测试的结果是J-link暂不支持MTB模块(但是支持ETB模块),所以我使用了OpenSDA平台的CMSIS-DAP固件来调用MTB模块,所以如果你手中有Kinetis L系列的Freedom板的话就直接可以跟我做了,其中CMSIS-DAP固件在本博客附件中,使用方法仍旧是类似更新OpenSDA的应用,不过换过CMSIS-DAP固件之后OpenSDA的小灯可能不亮,这个纯属正常,不要惊慌,哈哈。 测试环境:IAR6.6 + Freedom OpenSDA(CMSIS-DAP firmware) 测试目标芯片:Kinetis MKL25Z128     1)打开一个KL25的demo例程,然后右键工程Options->Debugger,选择“CMSIS-DAP”调试器,然后其他默认即可,设置完毕,点击“OK”,如下图所示:     2)点击调试按钮,进入调试界面,此时菜单栏会出现CMSIS-DAP选项,选择CMSIS-DAP->ETM Trace,调用MTB模块,弹出跟踪窗口,如下图所示。默认情况下跟踪功能是禁止的,此时点击跟踪窗口ETM Trace左上角的“电源符号”,打开跟踪功能,此时调试界面的左上角的ETM显示绿色,表示已经打开;     3)此时MTB功能已经打开,我们可以点击“全速运行”,然后再点击“暂停”,此时就可以在ETM Trace跟踪窗口看到从运行到断点停止这段时间所有的指令执行情况了,非常直观,如下图所示,此外可以选择同时查看汇编和C语言,也可以保存跟踪的结果,进而分析程序执行情况。     说到这,我们就该想到这种方式的好处了吧, 如果遇到Hardfault或者程序跑飞的时候,通过设置断点或者点击暂停,然后就可以捕捉到出现hardfault或者程序跑飞的之前的程序执行情况从而帮助我们快速定位到bug的地方, 非常方便实用。此外,实用CMSIS-DAP调试工具还有一个好处是,可以使用很多插件了,比如Timeline等等,灰常不错,哈哈~ English Version:     As we know, ARM Coresight, the ARM debug and trace technology, is the most complete on-chip debug and real-time trace solution for the entire System-On-Chip(SoC), making the ARM processor-based SoCs the easiest to debug and optimize. In this technology, the ETB in  Cortex-M3/M4 and MTB in Cortex-M0/M0+ are representative two units, which can effectively help us to monitor the process of software executing or focus on some hard faults by tracing the instructions.     In the article, I wanna introduce the MTB useage in our product Kineits L series, which may be helpful to some customers using KL chip. But, before that, a CMSIS-DAP firmware for OpenSDA platform is needed, which you can find in the attachment of this article. So far as I know, it seems that J-Link don't support MTB yet, but do support ETB of Cortex-M4. Testing Platform:     IAR EWARM6.6 + FRDM KL25 (OpenSDA with CMSIS-DAP fimware) Testing steps:     1) firstly, update the OpenSDA with CMSIS-DAP fimware, just like other OpenSDA applications;     2) open any KL25 demo with IAR, access project setting "Options->Debugger", and select the "CMSIS-DAP" adapter as the screenshot shown below;     3) click the debug button to access thw debug window, then click the CMSIS-DAP->ETM Trace from the menu bar,  and the ETM trace window will appear. Note that, the trace function is disabled in default, so another step is needed to click the "power port" at the top left corner to enable the trace function. The screenshot shows it below;     4) Now, the MTB is working. We can try it by click "run" and wait a while to click "pause", then the instructions from run to pause are shown in the trace window, it is really convenient. Besides, we can save, clear or zoom the trace results. Conclution:    Through the above method, some painstaking issues like hardfault or program fleet can be captured simply by setting breakpoints or mannuly pause, which can help to positioning the source of the problem. Beyong that, the CMSIS-DAP can support plugs like timeline tool. BTW, it is a pity that MTB unit in the new Kinetis E series is cut out.         Happy Tracing!
View full article
CONVOCATORIA Freescale Semiconductor, Inc. Convoca al primer concurso de proyectos “Kinetis L MCU Challenge México” “Kinetis L MCU Challenge México” es una competencia de proyectos tecnológicos basado en la herramienta de desarrollo Kinetis Freedom en la cual el participante construye una aplicación alineada a una de las futuras tres tendencias Salud y Seguridad, Efecto Net o Going Green. Los proyectos finalistas serán presentados durante la final del Freescale Cup 2013 el día 7 de Diciembre, a las 9:00hrs en el Centro de Congresos del Tecnológico de Monterrey Campus Guadalajara .  Si resultas ganador, viajarás con todos los gastos pagados al Freescale Technology Forum (FTF) en Dallas, Texas. ¿Cómo puedo participar? Regístrate en Kinetis Challenge antes del 15 de Noviembre de 2013 Crea una aplicación utilizando la herramienta de desarrollo Freedom (en caso de no contar con ella, puedes adquirirla a través de Element 14 (entrega al siguiente día laborable), Mouser (entrega en 4 semanas), o Digikey (entrega de 3 a 5 días hábiles) . Tienes hasta el 15 de Noviembre para subir la información de tu aplicación a la comunidad de Freescale (es necesario hacer log in con tu cuenta en www.freescale.com 😞 Nombre de la aplicación 1 párrafo descriptivo de la aplicación Un video descriptivo de hasta 2 minutos El código fuente en formato .zip Subir el proyecto como documento en la sección de Kinetis Microcontrollers en el siguiente formato:  https://community.freescale.com/docs/DOC-94067 El proyecto deberá contener el tag: "Kinetis L MCU Challenge México" para ser identificado como proyecto participante del concurso. Freescale seleccionará 10 proyectos finalistas basándose en los criterios descritos en la convocatoria. Éstos se presentarán en el evento Freescale Cup 2013 el próximo 7 de Diciembre de 2013. Para conocer a los finalistas ingresa aquí. El proyecto ganador, será elegido durante el evento Freescale Cup 2013 por los asistentes al evento, a través de la comunidad Freescale y redes sociales, basándose en los criterios descritos en la convocatoria. El anuncio del proyecto ganador y la entrega de certificados será el  día del evento. La elección del ganador está en tus manos, sigue las instrucciones aquí. ¡Descubre quién es el ganador aquí! Links de interés: Acerca de Otros Recursos Registro Freedom Development Platform Ejemplos de proyectos con Kinetis www.electronicosonline.net/kinetischallenge FRDM-KL25Z Compra de FRDM-KL25Z en Element14 Kinetis L Microcontrollers Compra de FRDM-KL25Z en Mouser Freescale Cup 2013 Compra de FRDM-KL25Z en Digikey FTF Americas 2014 Cómo subir tu proyecto
View full article
Trimming internal reference clock of ICS (internal clock source) module using OSDA connection Pavel Šádek, Rožnov, Czech Republic   Simple apps does not require crystal driven clock precision. Internal reference clock based timing of MCU can be used instead.   Manufacturing process yealds to frequency deviation, that is why all MCU devices are factory programmed with a trim value in a reserved memory location. This value is uploaded to the ICS_C3 register and ICS_C4[SCFTRIM] during any reset initialization. For finer precision, trim the internal oscillator in the application and set ICS_C4[SCFTRIM] accordingly.   The TRIM bits effect the ICSOUT frequency if the ICS is in FLL engaged internal (FEI), FLL bypassed internal (FBI), or FLL bypassed internal low power (FBILP) mode.   The internal reference clock can be trimmed also in program time of the device to any value between 31.25 and 39.062kHz, this allows also achieving exotic bus frequencies.  The value applied in Processor Expert does not propagate into Pemicro connection manager. No matter if Processor expert is used or not , we need to configure it it by ourselves in connection of OSDA (same for debugging or programming). So this is a guide how to do so.   In the program initialization we need to initialize the ICS_C3 register and ICS_C4[SCFTRIM]. It can be done siply this way:   /* System clock initialization */   if ( *(( uint8_t *) 0x03FFU) != 0xFFU) {     ICS_C3 = *(( uint8_t *) 0x03FFU);     ICS_C4 = (ICS_C4 & 0xFEU) | ((*(( uint8_t *) 0x03FEU)) & 0x01U);   }   Then hit   flag, choose debug configuration and you will see configuration of your connectons, I have here only OSDA for my Kinetis E Freedom board (it is similar across families of Kinetis, ColdFire or S08 just connection would be SWD, Jtag or BDM) You will get new window   Choose „Advanced Programming Options“ button     Enable calculating of Trim value and programming into Flash location. If the TRIM frequency is different from default, check the box to use custom one in valid range – the one you(or Processor Expert) have used for your timing calculations. Hit DONE and your effort is done!   Next, when you will launch debugging session by hitting bug on button these values will be applied.   My RESULT:   ICS_C3 was trimmed to value of 0x57 for 39.062kHz and 0x9B for 31.250kHz for my Kinetis E Freedom board. Precision is better then 1% in room temp. This is ok for serial comunication without need of crystal for example. Note: Values out from my discovered range of 0x57 – 0x9B leads to frequencies that are out of specification of ICS and should not be used for this exact device.  The limits will be slightly different for every single device.
View full article
Timer PWM Module presented by Ali Piña. Module Explanation Connection Diagram Output compare Configuration Hands-On Input Campture Configuration Hands-On Overflow Configuration Hands-On Modulo de Timer y PWM presentado por Ali Piña. Explicación del modulo. Diagrama de conexión. Configuración para output compare. Hands-on Configuración como Input Capture. Hands-On Configuración del Overflow. Hands-On
View full article
Example of integrating CMSIS3.20 into MQX4.0.x on the TWR-K70F120M (with floating point unit) using CW10.4 using the MQX4.0.2\mqx\examples\hello2 project. In the attached ZIP file (hello2twrk70f120m_CMSIS_FPU.zip) is a MSWord document detailing the steps used.  That document name is TWR-K70F120M_CMSIS_CW10.4_MQX4.0.x.docx. Regards, David
View full article
Example of integrating CMSIS3.20 into MQX4.0.x on the TWR-K60D100M (no floating point unit) using CW10.4 using the MQX4.0.2\mqx\examples\hello2 project. In the attached ZIP file (hello2twrk60d100m_CMSIS_NoFPU.zip) is a MSWord document detailing the steps used.  That document name is TWR-K60D100M_CMSIS_CW10.4_MQX4.0.x.docx. Regards, David
View full article
You probably have heard of what's new on Kinetis side of the house. YES, talking about KL02, measuring only 1.9mm x 2.0mm. Take a look at the picture in which this powerful ARM based chip gets compared real scale, and being this tiny yet delivers 60 percent more GPIO than the nearest competing MCU. :smileygrin:!!!
View full article
Introduction This document is being written to communicate the need for serialization of memory operations and events in an end application.  In addition, directions will be provided to properly serialize memory operations in the end application.  Memory operations and event serialization applies to all Kinetis devices but is only necessary in specific scenarios. These scenarios include memory writes and reads, clearing status flags, and changing mode control operations. Serialization of memory operations Serialization of memory operations or events is the action of guaranteeing that said memory operations or events are executed in a specific order.  This action is required when making a change to a peripheral module when that change must complete before continuing with program execution.  Users often make the mistake of assuming that since a peripheral register has been written to, the change is in effect immediately.  However, this is not always the case.  The Kinetis series devices implement a crossbar and peripheral bridge interface system that allows masters (the CPU, DMA, etc.) to interface with the peripherals.  The crossbar allows multiple masters to access the individual peripherals on the bus, and the peripheral bridge functions as a bus protocol translator between the crossbar switch and the slave peripheral bus.  Wait states can be inserted at either stage of the communication channel (crossbar or peripheral bridge).  When a master attempts to access a slave and another master is already accessing this slave or the slave is busy, wait states will be inserted.  If the access is a write, then the master's write is simply pushed to the peripheral bus and the master continues.  However, if the access is a read, the master must wait for a response from the slave.  The slave may insert wait states in this communication as it must finish any commands (or writes) it was previously given before responding.    Peripheral module changes that require serialization actions include clearing interrupt service flags, changing power modes (of the module or the SOC as a whole), or software triggering a hardware event.  If the events or memory operations are not serialized in these situations, the CPU could go on to execute code with undesired effects. When do I need to serialize my memory operations and events? Memory operations and events require serialization anytime the program needs to guarantee that a peripheral access happens before code execution continues.  Examples of these situations includes: Exiting an interrupt service routine (ISR) Changing a clock mode or power mode Configuring a function Configuring a hardware change Software triggering a hardware event How do I serialize my memory operations and events? Memory operations are serialized by performing the following operations: Write the desired peripheral register Read the peripheral register that was just written Continue with the subsequent operations By simply reading the register that was just written, the core is forced to wait for a response from the peripheral module that was written before code execution can continue.   In this manner, it is guaranteed that the peripheral module will have completed the desired operations. Example event serialization The following is an example of a function that services the LPTMR ISR flag and implements the event serialization discussed in this document.  void lptmr_isr(void) {   // Declare dummy variable to store the read of the LPTMR0_CSR register volatile int dummy_var; /****   STEP #1  ****/   // Clear the flag; enable interrupts; enable the timer   LPTMR0_CSR = ( LPTMR_CSR_TEN_MASK | LPTMR_CSR_TIE_MASK | LPTMR_CSR_TCF_MASK  );   /****  STEP #2  ****/    // Store CSR register in dummy_var to serialize the clearing of the TCF flag   dummy_var = LPTMR0_CSR; } Conclusion In conclusion, there are situations where code execution can continue before a peripheral change has taken effect. These situations include clearing interrupt service flags, changing power modes (of the module or the SOC as a whole), or software triggering a hardware event.   Sometimes these events can cause unexpected results or even cause your application to crash.  These situations call for the serialization of memory operations and events, which is simply the act of guaranteeing that events and code are executed in a specific order.  To serialize memory operations, simply follow these directions: Write the desired peripheral register Read the peripheral register that was just written Continue with the subsequent operations Following these steps, you will be guaranteed that peripheral configurations have taken effect before continuing with the application. 
View full article