Author Topic: M52235EVB_SEC_FLASH.lcf make the board err!  (Read 3342 times)

Offline tr111

  • Jr. Member
  • **
  • Posts: 72
    • View Profile
M52235EVB_SEC_FLASH.lcf make the board err!
« on: September 05, 2012, 05:51:14 AM »
 I use the M52235EVB_SEC_FLASH.lcf to make the uTasker_boot_secure.S19.
 then I program the uTasker_boot_secure.S19to the board ,
 but something is err when after  programed , the board can not earse and program.
 I never see the "
# * File:       M52235EVB_SEC_FLASH.lcf
# *             WARNING: don't use unless you want to secure the chip and have a method of unsecuring in emergencies!!
How can  I do??  to change the MCF52235.cfg in the CW7.1??

; Set VBR to the beginning of what will be SRAM
; VBR is an absolute CPU register
writecontrolreg 0x0801 0x20000000
writecontrolreg 0x0C05 0x20000021

; Set FLASHBAR (Flash)
writecontrolreg 0x0C04 0x00000061

; Enable PST[3:0] signals
writemem.b 0x40100074 0x0F
« Last Edit: September 05, 2012, 06:00:22 AM by tr111 »

Offline tr111

  • Jr. Member
  • **
  • Posts: 72
    • View Profile
Re: M52235EVB_SEC_FLASH.lcf make the board err!
« Reply #1 on: September 06, 2012, 02:37:27 AM »
I get from

Re: Erasing Secured Flash.Options
Mark as NewBookmarkSubscribeSubscribe to RSS FeedHighlightPrintEmail to a FriendReport Inappropriate Content....2010-06-15 11:20 PM

P&E Micro have an application that will unsecure the flash.


Click on "FAQs, Manual's & Download's"

Then look for UNSECURE CF on right side of page.


You must place the ColdFire device into JTAG mode (usually a jumper setting on the EVB).

Set jumper so PSTCLK goes to pin 6 rather than pin 24 on the BDM header.

Use the P&E USB Multilink hardware.



that mcf52235 and mcf52259 is ok!~

Offline tr111

  • Jr. Member
  • **
  • Posts: 72
    • View Profile
Re: M52235EVB_SEC_FLASH.lcf make the board err!
« Reply #2 on: September 06, 2012, 02:39:18 AM »
Table 17-7. CFM Security States
SEC[15:0] Description
1 This value was chosen because it represents the ColdFire HALT instruction, making
it unlikely that a user compiled code accidentally programmed at the security
configuration field location would unintentionally secure the flash memory.
Flash Memory Secured
All other combinations Flash Memory Unsecured!
Flash memory security bits
The SEC bits define the security state of the MCU as shown in Table 17-7, which defines the single code
that enables the security feature in the CFM
 * File:   flash_config.s

   .global FLASH_CONFIG
   .global _FLASH_CONFIG   

 * FLASH configuration
.long 0x11223344
.long 0x55667788
.long 0x00000000
.long 0x00000000
.long 0x00000000
.long 0x80004AC8

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3079
    • View Profile
    • uTasker
Re: M52235EVB_SEC_FLASH.lcf make the board err!
« Reply #3 on: September 06, 2012, 06:54:20 PM »

The secure startup file should be used very carefully since it disables the BDM interface to the processor. This means that, once activated, it is no longer possible to use the debugger.

When using the secure startup file with the uTasker "Bare-minimum" boot loader it should be loaded "together" with an application that can work together with it to allow further uploads. This application can also include a mass erase command that can be used to unsecure the device again.

If the "Bare-Minimum" Boot Loader is loaded alone it will secure the device and neither have any method of uploading new code or performing a mass erase.

To recover from the secured state it is necessary to perform a mass erase but this can not be performed over the debug interface since this is blocked.
There may be methods using JTAG, which I never used, but I have used EZPORT to unsecure a device since the mass erase command can be executed over it.

Generally I would tend to ensure that the code that is running (which is also securing the device) includes some method of executing a mass erase in the case of emergency. A simple method would be to reserve an input pin which the software reads on start up and do this if it is the "recovery" position. This will be acceptable in applications requiring code protection since a mass erase, used to unsecure the device, will of course also delete the code that is being protected and is no security weakness in this respect.