Standalone Flash Programmer

Posted on August 2, 2012 by Erich Styger

In Scripting, the Debugger Shell and Debugger Shell: Test Automation I was exploring how to use the Debugger Shell for automation. For my lectures at the university I need to program multiple boards with the same application. I don’t want (and need) a debugger for this: all what I need is a ‘Standalone Flash Programmer’: the ability to flash one or multiple boards without debugging.

Such a Standalone Flash Programmer is very useful too if I just have the application binary file (say S19 file) available. I do not need the project or compiler: all what I need is to flash that file. And this works very well with CodeWarrior/Eclipse too. Here is how I do this…

Workspace

I could use an existing workspace. But if I have a special ‘Programming PC’, then I start with a new workspace. A new workspace requires me to set up a launch configuration for the flashing, but that’s not that complicated (see below).

I start Eclipse with a new workspace:

Standalone Flash Workspace

From the welcome screen, I switch to the workbench:

Go To Workbench

Launch Configuration

What need now is a launch configuration I can use later in my script. For this I select the ‘Flash File To Target‘ menu:

Flash File to Target

I need to set up the Connection and the Flash Configuration. This depends a bit on the connection and target used. The details how to configure this is described in Flashing with a Button. If I need to setup memory or initialization scripts, then I can copy them from an existing project.

Once everything is set up, I have something like this:

Flash File to Target Dialog

Now I have a debug configuration I can use in my script. What is missing is the script itself. Instead to write it from scratch, it is easier to copy/paste from what CodeWarrior does…

Flash File to the Target

For this I press the ‘Erase and Program‘ button in the above dialog. This will erase the device and do the flashing. And it writes the debugger script commands executed to the Console view:

Executing Task with Output in the Console View

Debugger Shell

In order to use scripts, I need the Debugger Shell view. I open the Debugger Shell view using the menu Show > View:

Show View Debugger Shell

Then I copy-paste the commands from the Console view into a script file.

Note: Backslashes in paths *must* be doubled, and file paths have to be surrounded by double quotes!

Additionally I add extra commands and comments to the script file:

############################################################
# Standalone.tcl: a script file just to flash my application
############################################################

# in any case, disconnect an existing debug connection
fl::disconnect

# set launch configuration:
fl::target -lc "LC for Simple Flash"

# set Set the target RAM buffer for downloading image data:
fl::target -b 0x20000000 0xffff

# switch off verify and logging:
fl::target -v off -l off

# select flash device, organization and memory range:
cmdwin::fl::device -d "CFM_MCF5225X_512" -o "256Kx16x1" -a 0x0 0x7ffff

# specify target file, auto detect format, range settings on followed by the flash range, offset settings off
cmdwin::fl::image -f "C:\\tmp\\wsp_StandaloneFlsh\\Application.S19" -t "Auto Detect" -re on -r 0x0 0x7ffff -oe off

# now erase the flash...
cmdwin::fl::erase image

# ... followed by writing the application to flash:
cmdwin::fl::write

# disconnect connection
fl::disconnect

Hint: to get an online description of the commands, I type the ‘help’ command followed by the command of interest inside the Debugger Shell, e.g. ‘help fl::disconnect’. This will show me the list of options for that command.

I can run my script in the debugger shell, using the source command:

Executing Script in Debugger Shell

With this script file, I can execute the script several times to flash several boards: simply use the <cursor up> key to repeat a previous command.

Flashing Multiple Boards

How to flash multiple boards? This is done with a simple ‘for’ loop and with ‘read stdin 1′ to wait for a key pressed:

for {set i 1} {$i <= 10} {incr i} {
  puts "Waiting for board #$i connected. Press any key to continue."
  read stdin 1
  puts "Flashing board #$i"
  # perform flash programming here...
  puts "You can disconnect board now!"
}

Combined with previous script this gives this:

############################################################
# Standalone.tcl: a script file just to flash my application
############################################################

# in any case, disconnect an existing debug connection
fl::disconnect

for {set i 1} {$i <= 10} {incr i} {
  puts "Waiting for board #$i connected. Press any key to continue."
  read stdin 1

  puts "Flashing board #$i"

  # set launch configuration:
  fl::target -lc "LC for Simple Flash"

  # set Set the target RAM buffer for downloading image data:
  fl::target -b 0x20000000 0xffff

  # switch off verify and logging:
  fl::target -v off -l off

  # select flash device, organization and memory range:
  cmdwin::fl::device -d "CFM_MCF5225X_512" -o "256Kx16x1" -a 0x0 0x7ffff

  # specify target file, auto detect format, range settings on followed by the flash range, offset settings off
  cmdwin::fl::image -f "C:\\tmp\\wsp_StandaloneFlsh\\Application.S19" -t "Auto Detect" -re on -r 0x0 0x7ffff -oe off

  # now erase the flash...
  cmdwin::fl::erase image

  # ... followed by writing the application to flash:
  cmdwin::fl::write

  # disconnect connection
  fl::disconnect

  puts "You can disconnect board now!"
}

Now I can flash multiple boards, one after each other, with one script.

Happy Flashing 🙂

22 thoughts on “Standalone Flash Programmer”

Pingback: CodeWarrior Flash Programming from a DOS Shell | MCU on Eclipse
Vivek Sharma on September 5, 2012 at 20:49 said:

Awesome!!

LikeLike

Reply ↓
Nguyen Tien Hung on April 3, 2013 at 04:03 said:

So great!!
but I have a problem. My target does not run after flashing. I have to unplug power supply and then everything is ok.
anyone can explain what happen?
im using multilink universal of PE micro debugger and codewarrior 10.2

Thanks a lot..

LikeLike

Reply ↓
- Erich Styger on April 3, 2013 at 07:52 said:
  
  To my knowledge, the target is not reset after the flashing. So all what you need is to reset the board, or to power it up again.
  
  LikeLike
  
  Reply ↓
  - Nguyen Tien Hung on April 3, 2013 at 10:26 said:
    
    I reset by hardware button but target still not run, except unpluging power supply. I am running automation test (build , flash, and run..) so i can not do that (unplug power supply and plug again).
    
    LikeLike
    
    Reply ↓
    - Erich Styger on April 3, 2013 at 10:29 said:
      
      What microcontroller are you programming? It sounds to me like the P&E programmer is keeping the target in reset.
      Does the reset button work if disconnect the P&e cable first?
      
      LikeLike
Nguyen Tien Hung on April 3, 2013 at 10:47 said:

Reset button work fine in other cases. In my design, pin reset of P&E Programmer is not connected to MCU’ reset input.
MCU that Im using is Kinetis K20DX256.

LikeLike

Reply ↓
chiasyan on April 14, 2013 at 10:46 said:

Hi Erich,

I am having trouble loading my program into K20DX256 for the first time. In order to test the communication between P&E Multilink (JTAG) with the target, I have used this standalone flash programmer’s “Erase Whole Device” but end up getting the error message “cannot enter background mode”.

There is one statement in Multilink user manual, saying that “…make sure the processor oscillator is running…” which is one of the issue I am facing.

The symptoms of this problem has been discussed in the forum.

However, there is not solution presented. Please assist, thank you.

LikeLike

Reply ↓
- Erich Styger on April 14, 2013 at 12:43 said:
  
  is this your own/custom board? Then I would check first all the connection lines/etc. It could be that the problem is with the hardware/board.
  As for trying with the debugger: I would create a test project with the CodeWarrrior wizard (File > New > Bareboard project).
  Another comment I have: I have seen parts which had the wrong labels on it (means: the writing on the part was telling something, but the silicon inside it was different). Yes, errors can happen everywhere :-(. So I hope this is not your problem. The other thing is: the Freescale part numbering is very confusing and difficult to understand: e.g. there are different part numbers/device names for say different MHz parts. Bottom line is: I suggest that you have an existing hardware (e.g. a Freescale Tower Board) which you know is working. And then compare the diffference between the ‘working’ and ‘not working’ version.
  
  LikeLike
  
  Reply ↓
  - chiasyan on April 14, 2013 at 13:14 said:
    
    Hi Erich, thank for your quick response.
    
    Yea, it is a custom board and I have double-checked the connections.
    
    I will try again using the Bareboard project as suggested. However, since I am going to test just the JTAG communication, is it “okay” to create an empty project, build it and try to download it?
    
    The “…make sure the processor oscillator is running…” from Multilink user manual is still troubling me.
    
    Based on your experience, is the crystal really need to start running/oscillating before the JTAG could be connected?
    
    Thank you.
    
    LikeLike
    
    Reply ↓
    - Erich Styger on April 14, 2013 at 14:30 said:
      
      I believe you should be able to run the microcontroller just with the internal clock.
      
      LikeLike
Pingback: DYI Free Toolchain for Kinetis: Part 1 – GNU ARM Build Tools | MCU on Eclipse
Frederico on December 30, 2014 at 14:14 said:

Hi Erych,

I’m having the same problem chiasyan had.
Suddenly some of my KL05 appeared to be secured when I tried to program them using USBDM_SWD_SER_JS16CWJ. I’m workin on it withtou success. I cannot make a mass erase.
Using USBDM interpreter I get MDM-AP as 0x00000034, what means it’s mass erase enable.

USBDM softwares do not have an option to make a mass erase, so I get a PE Multilink Universal.
In KDS I created a new project, with no code, I build and configurated the debugger to flash the memory with a mass erase, but when I try I get the messages:

P&E GDB Server, Version 5.13.02.00
Copyright 2014, P&E Microcomputer Systems Inc, All rights reserved

Loading library C:\Freescale\KDS_2.0.0\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_1.1.7.201410171532\win32\gdi\unit_ngs_arm_internal.dll … Done.

Command line arguments: -device=KL05Z32M4 -startserver -singlesession -serverport=7224 -interface=USBMULTILINK -speed=5000 -port=USB1 -USE_CYCLONEPRO_RELAYS=0 -FORCE_MASS_ERASE=0
Device selected is kl05z32m4
User Specified Hardware Selection : Interface=USBMULTILINK and Port=USB1
Connecting to target.
P&E Interface detected – Flash Version 6.10

Device is Secure.

Device is secured. Erasing …
Can not enter background mode.
Device is Secure.

Device is secured. Erasing …
Unable to initialize PEDebug.

PE-ERROR: Failed to Initialize Target
Server running on 127.0.0.1:7224
Connection from “127.0.0.1” via 127.0.0.1
PE-ERROR: Target is not connected
Disconnected from “127.0.0.1” via 127.0.0.1
Target Disconnected.

I’m still wondering if I installed Multilink drivers correctly, but I think so, because it is known by KDS. I do no have so many chips, an this was not the first. Do you have ideais why it is no entering in this background mode?

Thanks.

LikeLike

Reply ↓
- Erich Styger on December 30, 2014 at 16:09 said:
  
  Hi Frederico,
  it really looks that you have permanently secured your device with USBDM, and there is no way around that :-(.
  it looks like USBDM is not failsafe. I remember seeing cases where programming of the device has been interrupted (by any means), then the device remains secured. Maybe you should not use USBDM to program your devices then 😦
  
  Erich
  
  LikeLike
  
  Reply ↓
  - Frederico on January 6, 2015 at 14:10 said:
    
    Thank you very much Erych. I will consider that, then I’m starting using the PE Micro Multilink Universal.
    I hope it get no problem now.
    
    LikeLike
    
    Reply ↓
  - Peter on September 28, 2015 at 15:59 said:
    
    Hi Erich,
    Comment on some of the replies re USBDM.
    
    USBDM does check for securing+mass erase protect so should not permanently secure a kinetis device. This is done in the programming firmware so should be reliable. I have had no devices secured in this fashion (thousands of devices have been programmed in lab classes!).
    
    The comments by Frederico indicate that the device is not permanently secured (based on the MDM-AP value he supplied). So it was not permanently secured by the USBDM programmer
    
    Kinetis devices can be difficult to program even when not secured due to various reasons e.g. SWD pins disabled, reset disabled, illegal instruction resets, watchdog resets etc. So there are plenty of possible causes for difficulty in programming.
    
    Finally – Another poster indicated that USBDM does not provide mass-erase.
    The stand-alone programmers have always had a mass erase option when programming.
    The GDB server also provides that feature.
    
    bye
    
    LikeLike
    
    Reply ↓
    - Erich Styger on September 28, 2015 at 20:38 said:
      
      Hi Peter,
      many thanks for that information and clarification, appreciated!
      Erich
      
      LikeLike
- sekhar on May 13, 2015 at 15:33 said:
  
  I too had the same problem. Later we came to a conclusion that due to improper connection between Multilink and the Target board it used to happen this or any voltage fluctations during programming gives this problem.
  
  LikeLike
  
  Reply ↓
  - Erich Styger on May 13, 2015 at 17:23 said:
    
    Make sure your electrical setup (power supply, power distribution) is fine. And of course that you do not have any current flows e.g. the wrong direction too.
    
    LikeLike
    
    Reply ↓
Barak Manos on March 10, 2016 at 13:04 said:

I am asking this in relation to a problem that I have previously described in response to another one of your (awesome) posts at https://mcuoneclipse.com/2016/02/26/merging-s19-files/#comment-80150.

It turns out that my Standalone Flash Task simply won’t program anything into the block (or sector, not sure about terminology) which spans from address 0xFC00 to address 0xFFFF.

I have several lines of code in the S19 file that I am trying to program, yet, those which need to go into that address-range are simply “ignored” (peeking into memory with a debugger, I see all but FFs, i.e., this address-range seems to have been erased but not programmed).

Here is my TCL script:

fl::target -lc “Bootloader”
fl::target -b 0x80 0x1400
fl::target -v off -l off
cmdwin::fl::device -d “MC13233C_FLASH” -o “64kx16x1” -a 0x8000 0x4bfff
cmdwin::fl::protect all off
cmdwin::fl::erase all
cmdwin::fl::image -f “Bin\\Bootloader.s19” -t “Auto Detect” -re off -oe off
cmdwin::fl::write
cmdwin::fl::protect all on

Would you happen to know what am I missing here?

Thanks 🙂

LikeLike

Reply ↓
- Barak Manos on March 10, 2016 at 15:13 said:
  
  Problem found.
  
  Invoking ‘protect all on’ erases the last sector (any idea why?).
  
  LikeLike
  
  Reply ↓
  - Erich Styger on March 10, 2016 at 15:32 said:
    
    Unfortunately I don’t have an idea.
    
    LikeLike
    
    Reply ↓