- Forums
- Product Forums
- General Purpose MicrocontrollersGeneral Purpose Microcontrollers
- i.MX Forumsi.MX Forums
- QorIQ Processing PlatformsQorIQ Processing Platforms
- Identification and SecurityIdentification and Security
- Power ManagementPower Management
- Wireless ConnectivityWireless Connectivity
- RFID / NFCRFID / NFC
- Advanced AnalogAdvanced Analog
- Neural Processing UnitsNeural Processing Units
- MCX Microcontrollers
- S32G
- S32K
- S32V
- MPC5xxx
- Other NXP Products
- S12 / MagniV Microcontrollers
- Powertrain and Electrification Analog Drivers
- Sensors
- Vybrid Processors
- Digital Signal Controllers
- 8-bit Microcontrollers
- ColdFire/68K Microcontrollers and Processors
- PowerQUICC Processors
- OSBDM and TBDML
- S32M
- S32Z/E
-
- Solution Forums
- Software Forums
- MCUXpresso Software and ToolsMCUXpresso Software and Tools
- CodeWarriorCodeWarrior
- MQX Software SolutionsMQX Software Solutions
- Model-Based Design Toolbox (MBDT)Model-Based Design Toolbox (MBDT)
- FreeMASTER
- eIQ Machine Learning Software
- Embedded Software and Tools Clinic
- S32 SDK
- S32 Design Studio
- GUI Guider
- Zephyr Project
- Voice Technology
- Application Software Packs
- Secure Provisioning SDK (SPSDK)
- Processor Expert Software
- Generative AI & LLMs
-
- Topics
- Mobile Robotics - Drones and RoversMobile Robotics - Drones and Rovers
- NXP Training ContentNXP Training Content
- University ProgramsUniversity Programs
- Rapid IoT
- NXP Designs
- SafeAssure-Community
- OSS Security & Maintenance
- Using Our Community
-
- Cloud Lab Forums
-
- Knowledge Bases
- ARM Microcontrollers
- i.MX Processors
- Identification and Security
- Model-Based Design Toolbox (MBDT)
- QorIQ Processing Platforms
- S32 Automotive Processing Platform
- Wireless Connectivity
- CodeWarrior
- MCUXpresso Suite of Software and Tools
- MQX Software Solutions
- RFID / NFC
- Advanced Analog
- Neural Processing Units
-
- NXP Tech Blogs
- Home
- :
- Translated Content
- :
- Multi Source Translation Content
- :
- 2389468_en-US
2389468_en-US
2389468_en-US
2389468_en-US
Hello, when debugging the FLM of the LPC1778, I found that the data was incorrect after writing data to 0x0-0x400 using the FLM. Now my debugger cannot connect to the chip. I have consulted the documentation and believe that the data written to the vector table is incorrect and does not match the data I want to write, resulting in an invalid checksum. The documentation indicates that an invalid checksum will cause the chip to enter ISP mode and wait for program download.
1. I want to know how to recover from this state?
2. Why does writing 0x0-0x400 cause problems in FLM, while writing 0x400-0x7FFFF works fine? Looking at the FLM source code, there's a parameter called SET_VALID_CODE that automatically modifies the checksum. Is there something wrong with this part?
The 0x0000–0x0400 area is not just a regular flash data area; it contains the boot vector table, the valid-code checksum at 0x1C, and the CRP configuration word at 0x2FC. An incorrect checksum will cause the ROM bootloader to determine that the user code is invalid and enter the ISP (In-Service Module). If 0x2FC is mistakenly written as the CRP pattern, it will also cause JTAG/SWD access to be restricted or even make it impossible to return to normal debug mode.
You can prioritize recovery by ISP:
P2[10] is pulled low, then the chip is reset, the bootloader takes over and enters ISP mode.
Connect to FlashMagic or an equivalent ISP tool via UART0:P0[2] / P0[3] to perform a full wipe or re-download a valid image.
If only the checksum is invalid, it should be able to be erased and restored after entering the ISP; if CRP1/CRP2 is mistakenly written, JTAG will be disabled, but the ISP still has a limited recovery path; if CRP3 is mistakenly written, the documentation states that it will completely block JTAG and the ISP, in which case it is basically impossible to recover through the regular ISP/JTAG.
BR
Harry