Hello,
I recently acquired a TWR-K70F120M. I'm using Code Warrior Development Studio for MCU v10.5 Special Edition.
Everything worked well with the Debug and Run options.
But when I manually reset the TWR, the program was no longer executed. So I tried to flash the program (bareboar project, no MQX, just the counter incrementation default code).
I specified the wrong file to flash on the target (the .project xml file). Since that moment, neither the Debug, Run, and Flash Program works (by specifying the right flash .elf file)
I already tried on another computer, with another CodeWarrior install, also tried to mass erase the target.
The error I get when trying to Flash Program is :
Downloading 0x000001E8 bytes to be programmed at 0x00000000
Executing program ....
Error: Program failed. Flash driver reports the following error(s): The flash device algorithm was interrupted during execution.
Please check if the flash base address is correct or if there are any flash devices mapped inside the selected memory space.
If a custom target initialization file was used then check the following parameters: flash base address, flash bank size and flash
bank port size.
Please enable Verify Target Memory Writes in Target Configuration to check that the algorithm downloads correctly. If you are down
loading the algorithm to DDR try checking your DDR configuration.
With the Debugger Shell I'm able to read the Flash (using the display command) and the xml file is still there.
When trying to read registers one by one (reg command), the target disconnects itself.
A fl::blanckcheck command leads to an <internal error>.
I would like to know :
- Where is located the program when Running or Debugging a program : is it sent instruction-per-instruction to the target ? or all goes in RAM even with the Flash build ?
- By downloading the wrong file what could be the cause of my problem ?
Thanks in advance
Best Regards, Clovis
已解决! 转到解答。
Hi Clovis,
Do you have Segger J-Link tool? If yes, you could try to download Segger J-Link Commander software from below link and enter "unlock Kinetis" commander to mass erase the chip .
SEGGER Microcontroller - Embedded Software Solutions - Download
Wish it helps.
Best regards,
Ma Hui
Hi Clovis,
Please kindly refer to the following for details.
- Where is located the program when Running or Debugging a program : is it sent instruction-per-instruction to the target ? or all goes in RAM even with the Flash build ?
If you use the Flash configuration, the program image is downloaded into the internal flash, otherwise SRAM configuration downloads the progam into the system RAM.
- By downloading the wrong file what could be the cause of my problem ?
There are a bit located in 0x40c(FSEC) controls the mass erase enablement, and Program flash protection bytes locate from 0x408 to 0x40B, so if the mass erase is disabled or some place in the flash is protected by the wrongly downloaded image, the mass erase would fail anyway. You may use Jlink to peroform the "unsecure".command to remove the above status.
Hope that helps,
B.R
Kan
hello,
regarding the security registers, everything is OK :
FPROT registers are at 0xFF (unprotected)
FSEC is 0xFE (backdoor disabled, mass erase enabled, failure analysis granted, flash secure disabled)
no errors neither on FSTAT register
regards, clovis
Hi Clovis,
Do you have Segger J-Link tool? If yes, you could try to download Segger J-Link Commander software from below link and enter "unlock Kinetis" commander to mass erase the chip .
SEGGER Microcontroller - Embedded Software Solutions - Download
Wish it helps.
Best regards,
Ma Hui
Thank you !
I misunderstood the registers : indeed, memory was write-protected
so I bought a J-link and succeeded to unlock !
Too bad that the embedded OSJTAG couldn't perform the unlock
Best Regards
Thanks for your response
Yes, I'm using the Flash target
Is there any chance that the corrupted code (which is still in Flash) initializes the registers so that the target become unprogrammable ?
best regards
Clovis
It need to check the Flash address 0x40C if set Chip in secured status. That could affect the JTAG to access the MCU.
More detailed info, I would recommend customer to check AN4507:
http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4507.pdf
Wish it helps.
Best regards,
Ma Hui