Messages

Dirk,

Please Email me your hex file that is causing this problem. My Email address is below and on the Flash Magic web page at the bottom. Thanks.

Version 1.79 of Flash Magic is now available and sets the status bit/byte BEFORE erasing the device, block 0 or page 0. Hopefully this will provide a more controllable situation when the device is not operating properly or the serial connection is not reliable.

Version 1.79 is now available with 669 support on the command line. Let me know if you spot any problems.

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.

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.

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.

If you are really looking for a customized version of Flash Magic with maybe some features removed, specific features added, rebranded to show your company name, device names replaced with product names, limited to specific or integrated hex files, etc., etc., then we can do that as well. Just send me an Email to the address below with your requirements so I can send you a quote.

Please Email me at the address below giving me your full name, title, company name, address and phone number. I will then find out if it is possible for us to license the source code. If it is I will send you an official quote.

You want the source code of Flash Magic itself, or you want the source code for an example Just In Time Module, or you want some other kind of example?

Please provide more details. Thanks.

Are you sure P2.6 and P2.7 are floating while programming? Why not temporarily pull them high during programming and check the voltages on the actual pins. If either of those pins was regarded as a logic 0 then strange behavior can occur.

Otherwise, I don't know why you were seeing the problems you were seeing. Unless you were using DTR and RTS to control /PSEN and RST, or you had the option in section 4 checked to execute the code, or you had the watchdog enabled, then your code should not have executed automatically after programming. Maybe you have some glitches on the RST pin or VCC?

OK. Try this. Download application note 4 from the Flash Magic web page and follow the steps in that document. It will lead you through some things to try. Let me know what you find out. My Email address is at the bottom of all my postings.

Hi Enrique,

When you programmed the second hex file did Flash Magic warn you that you were programming without erasing? If not then you still have Flash Magic set to erase something, and that is probably why your first hex file is dissappearing from the device.

When you program your hex file that is larger than 6k, which part of flash block 0 is unprogrammed? What address range? Does Flash Magic report any errors?

Please go to the Flash Magic web page, open application note 4 (what to do if ISP does not work) and perform the steps in section 5 (titled last resort). When performing those steps, only erase and program the hex file that is over 6k. When Emailing me the results also include the hex file itself and the answers to the questions above.

Flash Magic is limited to 96k of code in order to support the 89C669.

Andy

After trying to use Flash Magic and failing, put the device into the parallel programmer and read the value of the Boot Vector. It should be FCH. If it isn't then for some reason the Boot Vector is being corrupted. Please Email me for further assistance.

The 669 will be supported on the command line in the next release of Flash Magic.

The problem is the shortsightedness of computer manufacturers in omitting COM ports. OK, so that doesn't really help. We are seeing an increasing number of comments like this and usually they are solved by increasing the timeouts used in Flash Magic, which is not something the user can currently do. However, this makes Flash Magic painfully slow for everyone else using real COM ports. Therefore we are looking into a possible solution to suit everyone.