LPC Microcontrollers Knowledge Base

cancel
Showing results for 
Search instead for 
Did you mean: 

LPC Microcontrollers Knowledge Base

Labels

Discussions

Sort by:
经常有客户在使用LPC55S69的过程中遇到读 Flash进入异常HardFault中断的现象。如果在Flash Mass Erase之后从未对Flash扇区进行过写操作,直接用指针通过AHB读Flash地址会导致程序跳入HardFault 中断而无法继续正常运行。 原因    刚出厂的 LPC55Sxx FLASH 处于全零的全擦除状态,没有设置 ECC 。当芯片通过 LinkServer 和 MCUXpresso IDE 建立连接时,先擦除要下载代码用到的扇区,再把代码下载到对应位置,并对相应存储区的 ECC 值同时进行更新。代码以外的区域仍然是无 ECC 设置的擦除状态。 当 LPC55Sxx 通过 AHB 总线直接读取 Flash 内存区域时(例如,mytemp = *(uint32_t*)0x4000)要对 Flash ECC 进行校验。这一指令对于读有效代码区是没有问题的, 因为这一区域的 ECC 在下载代码时早已设置好。但是一旦读取没有代码的扇区,由于没有检测到正确的 ECC ,导致 Flash 读取失败,并跳转到下图中的 HardFault_Handler() 异常中断:   我们在 Sector Erase 后通过 AHB 读取 Flash 内存内容,也会遇到同样的 HardFault 异常跳转,出问题的原因都是一样的。 解决方法 针对这一问题我们有如下两种解决方法: 先执行 Flash 写操作,再读取 Flash 与 Flash 擦除操作不同,执行 Flash 写操作后对应的 ECC 值也同步更新。这样, ECC 校验通过后,通过下面的代码就可以对 Flash 直接进行 AHB 读取。 volatile uint32_t mytemp; …… mytemp = *(uint32_t*)0x1000;//read memory content 0x1000 to mytemp 请注意: 0x1000 必须是一个已经写过的地址。 如果 Flash 的某个扇区处于被擦除的状态,我们只需要在通过 AHB 总线读取内存区域之前对该区域执行写操作,这样 ECC 校验位更新正确后,就可以正常读 Flash 。 Flash 的写操作可以参考 MCUXpresso SDK 自带的 flashiap 例程,函数 FLASH_Program 。   使用 Flash 控制指令读取 Flash 区内容 使用Flash控制指令进行读操作不会导致硬件错误(请参阅 UM11126 “Command listing (CMD)” 章节)。这是用户手册中推荐的读Flash正确打开方式。 请注意: CPU 只有在频率低于 100MHz 时,才能进行 Flash 操作(读,写,擦除,校验,等等),当 CPU 频率超过 100MHz 时是不能实现上述操作的。 目前,官方没有提供上用控制指令读取 Flash 内容的例程,因此需要您根据下面步骤创建自己的读 Flash 程序。 开发环境: IDE: MCUXpresso IDE v11.1.0 SDK MCUXpresso SDK v2.7.0 步骤: 在 MCUXpresso IDE 中导入一个基础例程,如 led_blinky 在下图所述选项中添加 iap 组件   选择 iap1, 点击 OK   点击完 OK 之后,fsl_iap_ffr.h, fsl_iap.c, fsl_iap.h文件将自动添加到工程中   在 source 文件夹中添加附件中的 memory.h 和 memory.c 文件   4) 使用 Flash 控制指令时,需要在源文件中添加memory.h, fsl_iap.h   5) 调用 memory 初始化和 memory 读取函数   6)调试,单步执行( step over )到memory_read(),查看结果  
View full article
At the time of the latest update to this article, the latest silicon revision of the LPC55S6x is revision 1B. Since Nov,2019, all the LPCXpresso55S69 EVK boards marked as Revision A2 or A3 are equipped with revision 1B silicon. Initial production boards that have 0A silicon installed are marked Revision A1.                                     NXP introduced its new debug session request functionality on silicon revision 1B. For some IDE versions, the method of initiating a debug session is designed for current 1B silicon revisions and will r esult in an endless loop when used on older revision 0A parts due to the older revision not implementing some aspects of the handshake protocol. The protocol for this debug connection method, including handling of both 0A and later silicon revisions correctly, is included in the latest LPC55S6x/S2x/2x User Manual, section Debug session protocol.   IDE Considerations MCUXpresso IDE MCUXpresso IDE v11.0.1, incorrectly only supports silicon revision 1B debug session requests and cannot silicon to revision 0A parts in some situations. When connecting LPCXpresso55S69 Revision A1 board, you may have connection error like this: NXP released an MCUXpresso IDE v11.0.1 LPC55xx Debug Hotfix1 for this issue. Please follow the steps to fix the issue below if you have to use IDE v11.0.1 with silicon revision 0A; however it is recommended to update to the latest version of the IDE instead of taking this approach: https://community.nxp.com/community/mcuxpresso/mcuxpresso-ide/blog/2019/10/30/mcuxpresso-ide-v1101-lpc55xx-debug-hotfix IAR According to our test: IAR Embedded Workbench for ARM v8.42 and later can support both silicon revision 1B and 0A production without issue, which can be downloaded from https://www.iar.com/iar-embedded-workbench/tools-for-arm/arm-cortex-m-edition/ Note: The IAR 8.50.5 changed the CMSIS-DAP debug support for trustzone feature. There is known debug issue with the combination of IAR 8.50.5+SDK2.8.0. Thus our recommendation is:         Use IAR 8.50.5 with SDK2.8.0       Use IAR 8.40.2 with SDK 2.7.1   Keil MDK Both Keil MDK v5.28 and v5.29+ latest LPC55S69 pack v12.01 can support silicon revision 1B without problem but cannot support silicon revision 0A. LPC55S69 Revision 0A vs. 1B differences summary Silicon Revision 0A production 1B production Board Revision A1 A2 Deliver Date Before Nov,2019 After Nov,2019 Debug Access handshake Supported but not required. Handshake signaling partially supported Required Secure Boot Revision SB2.0 SB2.1 Maximum CPU Frequency 100MHz 150MHz IDE revision required 1.      MCUXpresso IDE v11.0.0 and older 2.      MCUXpresso IDE v11.0.1 + hotfix 1 3.      MCUXpresso IDE 11.1 and later MCUXpresso IDE v11.0.0 and newer SDK version SDK2.5 and newer are supported; SDK2.6.3 and newer are recommended SDK2.6.3 and newer     LPC55S69 Defect Fix: 0A vs. 1B 0A Production 1B Production Defect : For PRINCE encrypted region, partial erase cannot be performed Fixed Defect : For PUF based key provisioning, a reset must be performed Fixed Defect : Unprotected sub regions in PRINCE defined regions cannot be used. Fixed Defect : Last page of image is erased when simultaneously programming the signed image and CFPA region Fixed Defect : PHY does not auto-power down in suspend mode Fixed For more detail, see Errata sheet LPC55S6x which can be downloaded  from NXP web site.   Pre-production Silicon: Note that NO BOARDS WERE EVER SOLD THROUGH DISTRIBUTION WITH PRE-PRODUCTION SILICON. In case you have board marked with Revision 1, 2 ,A, or A1 board with 1B silicon, contact NXP to ask for production replacement.   Get Silicon Revision: The silicon revision info is marked on the chip and board revision is marked on the board silkscreen. For silicon revision marking information, please consult LPC55S6x Data Sheet section 4. Marking . Below is an example of silicon revision marking information where revision is highlighted in red: The user application can also get the silicon revision through chip revision ID and number: SYSCON->DIEID:     The English and Chinese version documents are attached.  
View full article
When we use LPC55Sxx PRINCE feature, we need enable PRINCE sub-region “crypto” by setting SR_ENABLE register. If we “crypto” enable discontinuous sub-regions and erase part of them, we may find we can’t erase/read/write other “crypto” sub-regions any more. This article will discuss how to resolve this phenomenon.           Figure 1         Testing Steps According to LPC55Sxx UM, each PRINCE region has its SR_ENABLEx register. This register enables PRINCE encryption and decryption of data for each sub-region of crypto region 0. Each bit in this field enables a sub-region of crypto region 0 at offset 8kB*n, where n is the bit number.  For example, when we set SR_ENABLE0=0X00000005, PRINCE region 0 sub-region 1 and sub-region 3 are set as encryption region. When read data out from these sub-regions, PRINCE will decrypt the data automatically.   Now we will test discontinuous sub-region erase/read/write. Board: LPC55S16-EVK IDE: Keil MDK v5.29 Step 1: PRINCE initialization: Enable PRINCE region 0 and two discontinuous sub-regions; generate key, IV code; enable crypto. //set SR_ENABLE , SR_ENABLE=0X28000000,enable sub-regions(0x30000-0x32000,0x34000-0x36000) crypto 。 status=PRINCE_SetRegionSREnable(PRINCE( prince_region_t )region0,0X28000000); //select PRINCE crypto for region0 PRINCE_SetRegionBaseAddress ( PRINCE_Type *base, prince_region_t region0, uint32_t 0X0) //generate PRINCE region0 crypto key Status=FFR_KeystoreGetKC(&flashInstance,&keyCode[0],kFFR_KeyTypePrinceRegion0); status=PUF_GetHwKey(PUF,keyCode,sizeof(keyCode),kPUF_KeySlot2, rand()); //generate PRINCE region0 crypto IV_code status=PRINCE_GenNewIV(kPRINCE_Region0,&prince_iv_code[0],true,&flashInstance) //load IV code to PRINCE status=PRINCE_LoadIV(kPRINCE_Region0,&prince_iv_code[0]) //enable PRINCE encryption PRINCE_EncryptEnable(PRINCE)   Step 2: Select two discontinuous sub-regions ( 0x30000-0x32000,0x34000-0x36000). Erase one of them (0x30000-0x32000), then write data to this sub-region. Output: Erasing and Writing are all successful. See Figure 2. //Erase 0x30000-0x32000 sub-region status=PRINCE_FlashEraseWithChecker(&flashInstance,0x30000,0x2000,kFLASH_ApiEraseKey); //Write 0x30000-0x32000 sub-region status=PRINCE_FlashProgramWithChecker(&flashInstance,0x30000,(uint8_t *)prince_iv_code,0x2000);   Step 3: Erase and Write the other sub-region ( 0x34000-0x36000 ) Output: Erasing and Writing are failed. See Figure 2. //Erasing 0x34000-0x36000 sub-region status=PRINCE_FlashEraseWithChecker(&flashInstance,0x34000, 0x2000,kFLASH_ApiEraseKey); //Write 0x34000-0x36000 sub-region status=PRINCE_FlashProgramWithChecker(&flashInstance,0x34000, (uint8_t *)prince_iv_code,0x2000); Error Analysis According to UM11126( 49.16.1 Functional details ) , each crypto region has its own SKEY and IV code. SKEY and IV are used together by the PRINCE when encrypting or decrypting the data in the sub-regions of crypto region. For Instance, For PRINCE region1, each time after we execute erasing operation, new Skey1 and IV1 are generated, thus when executing erase/read/write operation to another sub-region, the old IV1 and new IV1 don’t match, which causes PRINCE can’t decrypt correctly.   Suggestion We suggest user using SR_ENABLE to set continuous crypto sub-regions. When erasing operation is needed, erasing all the crypto sub-regions together, avoid erasing part of the sub-regions. One sub-region size is 8K, make sure the erasing/writing address 8K aligned.   Thanks for the suggestion from johnwu‌
View full article