topic USBDM Flash Programmer questions and comments in OSBDM and TBDML

USBDM Flash Programmer questions and comments

Obetz — Thu, 13 Jan 2011 18:17:26 GMT

Hello pgo,

thanks for this great tool!

After a quick try with a SH16 I think it's very well suited for low volume production programming.

Some questions and comments:

What is "Incremental File Load"?

How does "verify" handle the trim bytes? Could it be it that it verifies against the last trim result? In this case I had to manipulate the S19 file (exclude the trim bytes) to check the contents of an earlier programmed device (with unknown trim value).

Maybe verify could report the errors more detailed or read back the contents of a target to a file. Then one can use a text diff tool to find the differences.

Verify should use a different sound and a different dialog box for failed operations.

NVTRIM should be named NVFTRIM, NVTRIM is at $FFAF.

"Always in foreground" is somewhat annoying.

Oliver

Re: USBDM Flash Programmer questions and comments

pgo — Thu, 13 Jan 2011 22:08:42 GMT

Dear Oliver,

Documentation for the programmer is at:

http://usbdm.sourceforge.net/USBDM_V4.3/USBDM_FlashProgrammers/html/index.html

I believe this answers most of your questions. Please repost on any that are unclear.

The trim locations should be ignored if you select the trim option so it should allow verification of a previously programmed & trimmed device against a freshly loaded image.

The title NVTRIM is meant to be generic. It indicates the lowest addressed NV trim location - NV_ICGTRM_INIT or NV_FTRIM_INIT. In much of the Freescale documentation these locations are nameless. (The names mentioned are from Codewarrior) and also vary with clock type and target type (e.g. RS08 / HCS08). This could be clearer and in an earlier version of the programmer the names changed with clock type but I got a bit fed up with the amount of code required so it was lost when changing to wxWidgets . All the programmers now share the same dialogue code. One day I may be energetic enough to restore this.

I don't really think a more detailed report on flash differences would be that useful. I intended the verify as a pass/fail indication to allow you to check if the programming was successful or if a device contained the expected image.

A comparison would really fail for two different reasons - 1. A defect in the Flash in which case the whole device should be rejected and details would be unimportant IMO. 2. The image isn't what is loaded in the device. Even a small change in code would result in a very different flash images so again a detailed report would not have much value.

The dialogue has "keep on top" because it shares code with the GDI drivers which where appearing behind the codewarrior tools. This was the only solution I could find because the parent window is not available in the GDI DLLs and so parent-child window relationships were lost. I agree that this is annoying and it has been changed in V4.4.

I think I might be showing my age but I have never written a PC program that makes a noise. I think computers should be quite In this case I concede that a 'beep' on failure may be useful when programming multiple devices. If someone can provide linux/win32 code for a melodious beep I may incorporate this.

bye

Re: USBDM Flash Programmer questions and comments

Obetz — Fri, 14 Jan 2011 01:16:51 GMT

Hello pgo,

thanks for the link to the docs, they explain most I wanted to know. In the mean, I found the Doxygen sources of the Flash Programmer documentation, but I missed the "Provided Utilities" section.

I verified that the trim locations are ignored while trim is active. I can't reproduce exactly what I did before, maybe I deactivated trim but didn't reload the hex file, so I had the old value in the buffer.

Don't overrate the "stay on top" annoyance. I intend to use the programmer to program batches of 9S08, so during real application, it has to stay on top. Only while fiddling around (should be finished now), it's somewhat troublesome.

Regarding the beep: I agree with you, no reason to add custom sound options *). Don't waste time with it. But the dialog box should be more conspicuous on error. Maybe a double beep is an efficient method to get the "worker's" attention.

Again, the BDM interface and the Flash Programmer software is a great piece of work, many thanks for it!

Oliver

*) And counting >17000 days uptime, I'm also not that young.