Program a Device via Command Prompt

[TheMnemonic]

Hi all,

I'm working mostly with the MCF51JM128. Program it with Codebocks. So I'd like to program my device via the Command Prompt. For that I used the following Code:

CFV1_FlashProgrammer Project.S19 -vdd=5V -device=MCF51JM128 -program -verify

This works fine but unfortunately I got absolutely no information on my Command Prompt. Is there any possibility to see whats happening?

I also would like to apply power to my board after programming it. What command do I have to use for this?

Thank you very much for your help.

Regards,

Roman

[pgo]

Dear Roman,

The command line option works silently but it does return a error code that can be tested.  This can be used to produce a visible result.  An Windows example follows:

set FLASHCOMMAND=CFV1_FlashProgrammer.exe
set IMAGEFILE=TestMCF51CN128.elf.S19
cls

echo Verifying programmed image%FLASHCOMMAND% -device=MCF51CN128 -vdd=3v3 -verify -unsecure %IMAGEFILE%if not ERRORLEVEL 1 goto endecho Verifying image failedgoto end

:end

Currently there is no way to set the "leave target powered" option.  I'll add it in the next version.

bye

[TheMnemonic]

Hi pgo,

after your reply I tried out your code. Unfortunately I coudn't figure out how to make a proper download or even a verify.

1. If I Programm my Device via the command Prompt and the following code:

CFV1_FlashProgrammer Project.S19 -vdd=5V -device=MCF51JM128 -program -verify

The download will work, but the CFV1_FlashProgrammer.exe will remain in my Task-Manager.

2. If I Programm it via my batch file with the following code:

set FLASHCOMMAND=CFV1_FlashProgrammerset IMAGEFILE=project.S19 clsecho Verifying programmed image%FLASHCOMMAND%  -device=MCF51JM128 -vdd=5V -program %IMAGEFILE%if not errorlevel 1 goto endecho Programming failedgoto end :endecho end

 The batch-file stuck after executing the

%FLASHCOMMAND%  -device=MCF51JM128 -vdd=5V -program %IMAGEFILE%

line. And also the CFV1_FlashProgrammer will remain in the Task-Manager even. The Programming will also work but I do not get a single echo!

FYI: I'm using Windows 7.

regards,

Roman

[pgo]

Dear Roman,

It looks like there is a bug in the command line operation of the programmers that causes them to not exit (its waiting for GUI events but there is no GUI!).  This doesn't affect the non-commandline operation since there is a GUI.

I will fix this when I have some time.  I'm not sure in which version this crept in,

bye.

[pgo · Accepted solution]

Dear Roman,

The above bug has been fixed in V4.9.3 posted on sourceforge.

The '-execute'  option has been added to (I hope ) satisfy you other request,

bye

[TheMnemonic]

Hi pgo,

tested version 4.9.3 with my batch-file it works now.

thanks

regards

roman

[TheMnemonic]

Hi pgo,

its me again.

Tried to flash the MCF52259 (with no external reset circuit) with a batch file. The answer I get is:

Startup\Load\Flash_V2.batProgramming the image "bin\Release\Project.S19"UsbdmTCL incorporating TCL - Copyright(c) 2011bytesex => Big-endian:wCreg r=0x801(VBR)<-0x20000000:wCreg r=0xC05(RAMBAR)<-0x20000021:wCreg r=0xC04(FLASHBAR)<-0x00000061:wb FailedProgramming image failed

 Do you have any suggestions what might be the problem? It all works fine with the CFVx_FlashProgrammer. 

Batch-File code looks like this:

@echo offset FLASHCOMMAND=CFVx_FlashProgrammerset IMAGEFILE=bin\Release\Project.S19clsecho Programming the image "%IMAGEFILE%"%FLASHCOMMAND% -device=MCF52259 -vdd=3V3 -erase=All -unsecure -program %IMAGEFILE% -executeif not errorlevel 1 goto endexitecho Programming image failedgoto end :endexitecho All Doneexit:endpause

 thanks

regards

Roman

[pgo]

Dear Roman,

This is due to a silly error on my part.  There is part of a data structure that is not initialised properliy for CFVx when using the command line.

Unfortunately it's a bit difficult to fix because I am in the process of updating that code so I don't have a way of doing the simple fix required until I finish the other modifications - The build is current broken.

I will fix it as soon as I have completed the other changes.  This should be in a few days.

Sorry for the hold up.

bye

[TheMnemonic]

Hi pgo,

Ok no problems. Looking forward to have the new version :smileyhappy:.

There are also some details in the current version which I have noticed:

1. It looks like the Incremental file load doesn't work right. Or I missed its purpose. My understanding of this flag: it is for development purposes, so the FlashProgrammer loads the S19 file every time I flash a device. Right?

2. In the command prompt I cant define the Connection Speed.

3. There is still this reset-time issue.

If you need someone to test the new Version or just parts of it, just let me know.

Thanks

regards

Roman

[TheMnemonic]

Hi pgo,

just noticed another detail. In the case of an external powering the programmer can be set to have to power. So far so good. But in this case it would be very cool if after a successful flashing the device would restart and execute the program. Therefore the developer do not always has to plug and unplug the programmer from the hardware.

regards

Roman

[pgo]

Dear Roman,

1. It looks like the Incremental file load doesn't work right. Or I missed its purpose. My understanding of this flag: it is for development purposes, so the FlashProgrammer loads the S19 file every time I flash a device. Right?

 The incremental load does something entirely different - See the description in the Programmer manual.

2. In the command prompt I cant define the Connection Speed.

No - It works at a fixed speed - I will probably change this eventually but I would expect the default speed to be suitable for most targets.

3. There is still this reset-time issue.

 The next version will allow the reset parameters to be specified.  This may address this problem but I was suprised the last posted version didn't help so I may be mistaken in what the problem is.

just noticed another detail. In the case of an external powering the programmer can be set to have to power. So far so good. But in this case it would be very cool if after a successful flashing the device would restart and execute the program. Therefore the developer do not always has to plug and unplug the programmer from the hardware.

The next version will have an "load & go" option to do this \.

ETA = I'm currently testing this version.

bye

[TheMnemonic]

Dear pgo,

1. Ok right, I missed its pupose. But this leads me to a next question, why do you just load the hex file once, and not everytime I click "Program Flash", cause if one is a developer it is necessery to reload/reselect the Hex-File at any new compilation. If the file would be loaded everytime it would be much comfortablier, as one only has to push the "Progam Flash" button.

2. Ok.

3. Well I guess I'll test it with the new Version then. By speaking of tests, as I sead before if you'd be glad for some tests, just let me know. I mainly work with the MCF51JM128, MCF5212, MCF5213 and the MCF52259.

For the "load & go" option, looking forward to the new Version.

regards

Roman

[pgo]

Dear Roman,

V4.9.4 Files have been uploaded on Sourceforge.

I would appreciate it if you would try this with your hardware and let me know how it goes.  In particular whether changing the reset/power  options affect your success with the CFVx devices.

https://sourceforge.net/projects/usbdm/files/Version%204.9/1.%20Installation_4_9/

bye

[TheMnemonic]

Hi pgo,

first of all sorry for my late reply and thanks for all the changes you've done. Really appreciate it.
    
So now to the tests.
After no success in finding a working resettime, I took my oscilloscope again and checked all the signals.
While most of the singals were good, the reset,gnd and also vdd looked very very ugly, leading the DS13388 to hold the reset.
So my first guess that the supplyvoltage (which sometimes troped to 2.6v) lead the DS133388 (critical Supplyvoltage for a reset typ:2.88v) to hold the reset.
So as a first attempt I put a 10uF/16V Capacitor into the Supplycircuit of the programmer, thereby I got a more stable Supply of 3.2V but unfortunately still couldn't programm my devices.

So I focused on the reset line. With a closer look I noticed that it exhibits a 80MHz ripple. As this is exately the Frequency my uC runs with, I check the other signals for this Frequency.
And I found it at the SCLK-line. So as on the flat ribbon cable the reset and SCLK lines are really close to getter I checked the capacitence between those to lines. With 8pF I got a resistance of 250 Ohm with which it is obvious that my reset-signal gets mixed up.
So splitting the cable into two parts ( one with the rest and the other one with the SCLK ) and maximized the gap between, solved my problems (temporarily).
Now as the same cable works fine with the P&E Programmer, I checked the Lines there, noticed that they put the SCLK-line to a much lower frequency (around 2MHz) much earlier.
This prompts the following question:
Is it possible to set the SCLK-line to a lower frequency much earlier, and thereby getting much more stable and nicer signals?

thanks for all this, really like my new download environment and also its support :smileyhappy:.
    
Greetings
Roman

[pgo]

Dear Roman,

The USBDM BDM doesn't drive the SCLK (TCLK?)  line at 12 MHz during reset.

Does your board isolate the PSTCLK signal from pin 6 of the Debug connector when operating in BDM mode (as opposed to JTAG mode)?  The usual practice is to have a 3-pin jumper to connect the  PSTCLK/TCLK pin of the CPU to either P6 or P24 of the bdm connector - but not both. 

This may account for the 12 MHz signal as USBDM doesn't load the TCLK pin initially so any signal appearing would be unloaded.

Measurements on my hardware didn't have significant signals unless I put the 'jumper' in the wrong location.

The P&E BDM may be driving the TCLK pin low in BDM mode which would reduce the size of the clock signal.  If I remeber correctly it also terninates the PSTCLK signal would would also reduce the magnitude (and coupling).

bye

[TheMnemonic]

Hi pgo,

well yes it doesn't drive the TCLK (sorry the SCLK was my mistake) but the MCF52259 does it with 80MHz.

---

Does your board isolate the PSTCLK signal from pin 6 of the Debug connector when operating in BDM mode (as opposed to JTAG mode)?  The usual practice is to have a 3-pin jumper to connect the  PSTCLK/TCLK pin of the CPU to either P6 or P24 of the bdm connector - but not both.

---

In the image (attachement) you see the schematic of my BDM connector. In this configuration I do not have a  jumper.

---

pgo wrote:

Measurements on my hardware didn't have significant signals unless I put the 'jumper' in the wrong location.

---

What exactely is the wrong location? Is it possible that the bdm-conection on my board is bugy?

---

pgo wrote:

The P&E BDM may be driving the TCLK pin low in BDM mode which would reduce the size of the clock signal.  If I remeber correctly it also terninates the PSTCLK signal would would also reduce the magnitude (and coupling).

---

So whats the reason that USBDM don't drive the TCLK low? And a much bigger question, what is the TCLK for anyway?

regards

Roman

[pgo]

Dear Roman,

I've attached an example of the BDM connections for a CFV2 board I designed,  The "3-pin jumper" I refer to is JP2 in this diagram.

This design agrees with several of the Freescale Reference designs so I believe the use of a jumper is common practice.

The TCLK/PSTCLK is a shared pin.  In BDM operation it has the CPU clock output and is used to clock out some debug information (not used by USBDM).  In JTAG mode it becomes the JTAG clock input and is used by USBDM to "unsecure" the chip.  This seems a rather poor design choice but it's the way it is.  It really makes the jumper necessary.

Due to limitations in the "economy" circuit used in the USBDM it is not possible to independently drive the TCLK pin in BDM mode.  In any case this would conflict with the PSTCLK signal being an output. 

bye