As I pointed out earlier, running 89C4x0ldr-lite in this fashion will not be productive. If you would like "double-click" access to the software, you could set up a Windows shortcut that points to 89C4x0ldr-lite.exe and invokes it with the desired parameters.

I think Windows 98 is going to be a problem here. I did not have any Windows 95/98/Me/NT4 machines available for testing during development, and I would not be the slightest bit surprised if the software does not work properly on these platforms. Given their age and declining relevance, I did not think there would be much call for compatibility with them. Please let me know how your investigation goes; I am still interested in knowing what kind of experience you have with the software on these systems.

As a quick note, it is worth mentioning that 89C4x0ldr-lite is not concerned by what development environment or language you use to write your programs. In fact, it does not even care what type of file you try to load on to your microcontroller; it performs no verification of the input file whatsoever. However, your microcontroller will reject anything that is not a properly formed Intel hex file, and 89C4x0ldr-lite will pass this on to you in the form of an error message (for verbosity levels of 1 or greater) and a nonzero return code.


If you can get 89C4x0ldr-lite to run (this will most likely require a newever version of Windows), try running it with the "-V4" option; you will then have a much better idea as to where/why your load is failing. There is a detailed error message for every documented response from the ROM loader during a flash load operation.

You are correct that the microcontroller verifies the file as it is being received (at least when using the loading mode used by both MTK and 89C4x0ldr-lite), but this verifcation is limited to integrity checking of the hex file; no verification of any sort is actually performed on the code you are trying to load. If you can get a success message from 89C4x0ldr-lite, I would be reasonably confident that the microcontroller has in fact been programmed correctly according to the contents of the hex file.


Yes, you should. It is possible that you have a bad part, but there are some relevant programming-related errata for the DS89C420. Check the errata for the particular revision level of the device you are using: DS89C420A1 or DS89C420A2.


I have not had this experience; part of my testing of 89C4x0ldr-lite involved disconnecting the serial cable during programming to demonstrate that 89C4x0ldr-lite would correctly detect the failed communication. After doing that, I would reconnect the serial cable, rerun 89C4x0ldr-lite, and programming would proceed normally.

In addition to looking over the errata, please confirm that your in system programming hardware is correct; I would even suggest looking at the output with an oscilloscope. One problem I ran into recently in a system with elaborate in system programming protection is that the upon exiting from ISP mode, the reset line was brought low before /EA was brought high. As a result, my code was not running; this was of course because the device was trying to execute code from external program memory rather than the internal flash.

--Sasha Jevtic