- NXP 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
- MCX Microcontrollers
- S32G
- S32K
- S32V
- MPC5xxx
- Other NXP Products
- Wireless Connectivity
- 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
-
- 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
- Vigiles
- GUI Guider
- Zephyr Project
- Voice Technology
- Application Software Packs
- Secure Provisioning SDK (SPSDK)
- Processor Expert Software
-
- 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
-
-
- Home
- :
- CodeWarrior
- :
- CodeWarrior for MCU
- :
- HCS12 Unable to Single Step through EEPROM write +
HCS12 Unable to Single Step through EEPROM write +
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
SOLVED
12-08-2006
12:53 AM
1,835 Views
YeOldeBDM
Contributor III
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi. I just inherited a project from an outside consultant and his notes give the following limitations-
-Cannot single step through routines which write to the onchip EEPROM
-Cannot break/resume with WDT enabled (most of the time).
-EEPROM does not retain contents between BDM debug loads (of course the entire memory is flashed from debug session to debug session)
I have verified the limitations, and the consultant did spend some time trying to resolve them last year with freescale tech support. Now the project is alive again.
I am using Codewarrior 3.1 for HCS12. We are using an external oscillator, so there are no PLL issues.
Does anyone have any pointers to documentation on these limitations? I googled but did not find anything. I just want to know if these are known issues or if there are any work-arounds.
I read somewhere on this board that Codewarrior 4.5 may allow the EEPROM to be preserved between ICD debug sessions, but at this point I don't have time to upgrade
Thanks!
Solved! Go to Solution.
1 Solution
12-08-2006
01:31 PM
467 Views
Lundin
Senior Contributor IV
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
-Cannot single step through routines which write to the onchip EEPROM
That's right. The manual, chapter "4.1.4 Illegal EEPROM Operations":
"The part enters STOP mode and a program or erase command is in progress. The command is aborted and any pending command is killed."
-Cannot break/resume with WDT enabled (most of the time).
Of course not. Don't debug with the wdog enabled and you'll be fine.
-EEPROM does not retain contents between BDM debug loads (of course the entire memory is flashed from debug session to debug session)
That one is trickier. You can do it in Codewarrior if you use the old "cmd"-files. In preload.cmd, write:
reset
FLASH
FLASH SELECT
FLASH UNPROTECT
FLASH ERASE 1-8
FLASH ARM
1-8 is the page numbers, for an HCS12 with 8 pages of flash (128k). If you just write FLASH ERASE without any numbers it will erase the whole memory, including the EEPROM which is page 0 if I remember correctly. By adding 1-8 it will only erase the flash.
That's the only way I know of. You might have to set the debugger to "load code + symbols" instead of "load code to nvm" for it to work, since the latter is the new feature introduced in CW3.0 and not compatible with cmd-files. Or so did Metrowerks tell me back then.
That's right. The manual, chapter "4.1.4 Illegal EEPROM Operations":
"The part enters STOP mode and a program or erase command is in progress. The command is aborted and any pending command is killed."
-Cannot break/resume with WDT enabled (most of the time).
Of course not. Don't debug with the wdog enabled and you'll be fine.
-EEPROM does not retain contents between BDM debug loads (of course the entire memory is flashed from debug session to debug session)
That one is trickier. You can do it in Codewarrior if you use the old "cmd"-files. In preload.cmd, write:
reset
FLASH
FLASH SELECT
FLASH UNPROTECT
FLASH ERASE 1-8
FLASH ARM
1-8 is the page numbers, for an HCS12 with 8 pages of flash (128k). If you just write FLASH ERASE without any numbers it will erase the whole memory, including the EEPROM which is page 0 if I remember correctly. By adding 1-8 it will only erase the flash.
That's the only way I know of. You might have to set the debugger to "load code + symbols" instead of "load code to nvm" for it to work, since the latter is the new feature introduced in CW3.0 and not compatible with cmd-files. Or so did Metrowerks tell me back then.
2 Replies
12-13-2006
10:01 PM
467 Views
YeOldeBDM
Contributor III
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the info!
12-08-2006
01:31 PM
468 Views
Lundin
Senior Contributor IV
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
-Cannot single step through routines which write to the onchip EEPROM
That's right. The manual, chapter "4.1.4 Illegal EEPROM Operations":
"The part enters STOP mode and a program or erase command is in progress. The command is aborted and any pending command is killed."
-Cannot break/resume with WDT enabled (most of the time).
Of course not. Don't debug with the wdog enabled and you'll be fine.
-EEPROM does not retain contents between BDM debug loads (of course the entire memory is flashed from debug session to debug session)
That one is trickier. You can do it in Codewarrior if you use the old "cmd"-files. In preload.cmd, write:
reset
FLASH
FLASH SELECT
FLASH UNPROTECT
FLASH ERASE 1-8
FLASH ARM
1-8 is the page numbers, for an HCS12 with 8 pages of flash (128k). If you just write FLASH ERASE without any numbers it will erase the whole memory, including the EEPROM which is page 0 if I remember correctly. By adding 1-8 it will only erase the flash.
That's the only way I know of. You might have to set the debugger to "load code + symbols" instead of "load code to nvm" for it to work, since the latter is the new feature introduced in CW3.0 and not compatible with cmd-files. Or so did Metrowerks tell me back then.
That's right. The manual, chapter "4.1.4 Illegal EEPROM Operations":
"The part enters STOP mode and a program or erase command is in progress. The command is aborted and any pending command is killed."
-Cannot break/resume with WDT enabled (most of the time).
Of course not. Don't debug with the wdog enabled and you'll be fine.
-EEPROM does not retain contents between BDM debug loads (of course the entire memory is flashed from debug session to debug session)
That one is trickier. You can do it in Codewarrior if you use the old "cmd"-files. In preload.cmd, write:
reset
FLASH
FLASH SELECT
FLASH UNPROTECT
FLASH ERASE 1-8
FLASH ARM
1-8 is the page numbers, for an HCS12 with 8 pages of flash (128k). If you just write FLASH ERASE without any numbers it will erase the whole memory, including the EEPROM which is page 0 if I remember correctly. By adding 1-8 it will only erase the flash.
That's the only way I know of. You might have to set the debugger to "load code + symbols" instead of "load code to nvm" for it to work, since the latter is the new feature introduced in CW3.0 and not compatible with cmd-files. Or so did Metrowerks tell me back then.
