Main Menu

Rx2 with and w/o H

Started by erik malund, August 13, 2003, 08:16:29 AM

Previous topic - Next topic

erik malund

Will Flashmagic automatically sense the 'H' or do I have to change part number for boards with the non-H chips?
I can not require people in the field to open the box and check the chip before loading an update.

Erik

Andy Ayre

Currently, no. Flash Magic does not sense which part is which. The usefulness of checking the signature bytes is limited because some signature bytes are duplicated in different device families. Let me ask you this - how are you handling the clocks/cycle setting? The H devices defaults to 6 clocks/cycle, but the non-H devices defaults to 12 clocks/cycle. Do you need to load different hex files into each device also? I'm asking because I'm wondering what other ideas I can come up with to solve this problem.

Embedded Systems Academy, Inc.
support at esacademy dot com

erik malund

The H devices defaults to 6 clocks/cycle, but the non-H devices defaults to 12 clocks/cycle
I have not yet seen the non-H, but intend to test the following:
1) Initially all chips are parallel programmed.  Only field updates are IAP.
2) The sfr seting 6 clock mode in the non-H does not exist in the H so setting it to 6 clock in the H should have no effect.
3) I would not object to adding an 'inquire' function in my code if FlashMagic supported some such.
4) No pins will be fidddled with, IAP is strictly NoTouch.
5) if everything else fails (I hope not) I will have to set up a 'pre FlashMagic program' that does the necessary (hopefully without operator intervention) and inquire my code in the chip as to what it is.  That solution, however, screams human error potential.

Erik

Andy Ayre

My ideas so far are the following:

1. An option to generate a warning if the signature bytes do not match the selected device at the start of each ISP operation. This will not always determine the correct device however, but will tell the difference between H and non-H devices.

2. An option to have flash magic send something to the device and expect a specific response back before programming. This would effectively be an enhanced startbootrom option where the returned value is not always a '.' but something specific. The result can then be displayed to the user in some customizable way, for example "select device x".

3. Use the command line version of Flash Magic, read the signature bytes and process the results in a small program. Load the appropriate hex file. This is already possible. You just have to write the program that calls Flash Magic and processes the result.

4. You would like us (as a consulting job) to create a customized Flash Magic which can do whatever you need, and even reduce it to selecting product names/revisions rather than devices. Alternatively we can create the control program mentioned in idea 3.

Out of the non-consulting ideas, I think I am leaning towards number 2. Erik - let me know what you think.

Embedded Systems Academy, Inc.
support at esacademy dot com

erik malund

2. An option to have flash magic send something to the device and expect a specific response back before programming.

That would, as far as I can see be the same as my 3)

This would effectively be an enhanced startbootrom option where the returned value is not always a '.' but something specific. The result can then be displayed to the user in some customizable way, for example "select device x".

Well, "displayed to the user " will not do much good, "fetchable by a batch file" will.

3. Use the command line version of Flash Magic, read the signature bytes and process the results in a small program. Load the appropriate hex file. This is already possible. You just have to write the program that calls Flash Magic and processes the result.

Andy, what I am up against is customers, one of which, replied to a statement about reading instructions "we can not afford to hire people that can read" so I need a method of "insert cable, push button on laptop"

Erik


Andy Ayre

Well, one other idea I had was a general purpose scripting language that would allow you to read the signature bytes then perform any ISP operation, etc. but that is probably beyond my time constraints right now, unless I can find some shortcut to parsing a script.

We did do a customized version of Flash Magic for a user which was literally - select com port, select product, select hex file, click on Start. So it was really a cut down version, but came pre-configured. Behind the scenes it sent the start bootrom command, reset the device after programming, etc.

Embedded Systems Academy, Inc.
support at esacademy dot com

Joe F

>1) Initially all chips are parallel programmed. Only field updates are IAP.
>2) The sfr seting 6 clock mode in the non-H does not exist in the H so >setting it to 6 clock in the H should have no effect.

The non-H chips can be set to 6-clock mode during the parallel programming, and your operational code won't need to fiddle with the clock SFR at run time.  You can then run the same code on H and non-H parts, assuming that your IAP routines are written to detect and support both types.  (The IAP library offered on this site is for H parts only.)  

Joe