Firmware patch for building with SDCC and coressponding opgui patch (also includes rudimentary support for AT89S52)

[m-a-n-j-u]

Hello to everyone on this forum, this is my first post here and I'm sorry it is rather long. Many thanks to Alberto and the other contributors for developing this great open source programmer.

I built a few prototypes of Open Programmer and they worked very well for programming PIC and AVR devices. I wanted to add support for programming AT89 family of devices. I began with only AT89S52 at the moment, since that is the only AT89 device I have on hand currently.

I made changes to opgui code and got rudimentary flash memory write working (it only supports byte mode Program Memory access operations currently). However, reading the Program Memory shows some strange behavior which I have described below. I can confirm that programming itself works by observing the execution of the program on the AT89S52 target board. I can also read back the Program Memory contents correctly using a different programmer.

Here is a description of the problem:

An example of Program Memory write operation (Address: content bytes at offsets 0, 1, 2, ...):
0000: 0A, 0B, 0C, 0D, 0E, 0F, ....
Reading back the Program Memory using some other programmer shows the same content as above. However in case of Open Programmer it shows this:
0000: 0A, 0A, 0A, 0B, 0C, 0D, ....

So it seems an old value repeated when reading at address 0001 and 0002. And when reading from address 0003, I get the value which was supposed to be at 0001 and so on. The rest of the Program Memory reads fine, except that each byte has been offset to its address + 2. I have tried adding or changing delays (like WAIT_T3) but the problem does not resolve. This problem occurs both during consecutive 'byte-by-byte read operation', as well as during 'write a byte and read it back for verification' operation.

I wanted to take a closer look at SPI_READ instruction in the Firmware, although I don't think anything can be wrong with it since it works quite well for AVR devices. I wanted to make some small changes in the Firmware to help me debug this issue. So that is how I ended up porting the firmware over to SDCC, since I do not have (* more like I do not want to have) MPLAB or other tools that could build the firmware.

Originally my intention was to release more complete patches with good support for AT89 devices. However the above problem has left me stumped. So I'm posting my changes so far with the assumption that they may still be of use to someone and also with the hope that someone may help find a solution to the above problem.

---

Description of patches (I'm not sure if I can attach these to my post, but I'll find some way to share them):
Firmware_0.9.0_SDCC_changes.patch

• Contains changes required to build the firmware using SDCC
• No new features were added
• Firmware built with SDCC will not work if opgui is not patched

opgui_0.9.1_SDCC_firmware_and_AT89S_changes.patch

• Increases delays to support firmware built with SDCC, which is very slow
• This is enabled only when SDCC_FIRMWARE=1 is passed to make
• Adds rudimentary support for AT89S52
  • Read fails, Write throws errors, but programs seem to run correctly on the target hardware
  • Writing lock bits is not supported yet

(Linux) Instructions for patching and building opgui:

    tar -xf opgui_0.9.1.tar.gz
    cd opgui
    patch -p1 < {path}/opgui_0.9.1_SDCC_firmware_and_AT89S_changes.patch
    make SDCC_FIRMWARE=1

(Linux) Instructions for patching and building Firmware:

    unzip Firmware_0.9.0.zip
    cd Firmware
    patch -p1 < {path}/Firmware_0.9.0_SDCC_changes.patch
    make -f Makefile_SDCC

I have not yet been able to resolve the following types of warnings that occur when building the firmware with SDCC:

• warning 94: comparison is always true resp. false due to limited range of data type
• warning 110: conditional flow changed by optimizer: so said EVELYN the modified DOG
• warning 126: unreachable code
• warning: Processor mismatch (when linking some object files)

But I suppose we can temporarily ignore them since the firmware seems to work fine.

These are the versions of tools I used for building the firmware:

• sdcc-3.4.0
• gputils-1.4.0

I could only build and test the firmware for PIC18F2550 based programmer hardware, since I currently do not have the other supported parts.

[m-a-n-j-u]

Firmware patch

• This patch is not needed unless someone wants to develop the firmware further using SDCC.

• Produces a working firmware when built with SDCC, but does not contain any other updates or features over the Firmware_0.9.0 release.

• If firmware is built using SDCC, opgui needs to be built with "make SDCC_FIRMWARE=1". Otherwise programming most devices will result in timeout related errors.

Patch and build instructions (Linux):

unzip Firmware_0.9.0.zip
cd Firmware
patch -p1 < {path}/Firmware_0.9.0_SDCC_changes.patch
make -f Makefile_SDCC

[m-a-n-j-u]

opgui patch

• Adds support for AT89S52
• Currently it only supports byte mode programming (slower) and page mode programming is not supported.

Patch and build instructions (Linux):

tar -xf opgui_0.9.1.tar.gz
cd opgui
patch -p1 < {path}/opgui_0.9.1_SDCC_firmware_and_AT89S_changes.patch

If building for official Firmware_0.9.0 release:

    make RETRIES=1

If building for firmware built with SDCC:

    make SDCC_FIRMWARE=1 RETRIES=1

Without "RETRIES=1", AT89S52 programming fails.

[Alberto Maccioni]

Hello, your contribution is very welcome.
I think there is no need for a different firmware version, as regular SPI frames are involved in the programming process.
Also I don't see the need to change the communication routine; if you want to wait until a response is ready you need to use PacketIO() instead of read() and write().
Logging or debugging should reveal the cause of your problems; I think you are complicating the issue by modifying the firmware.
Can you post or send me a write and a read log?

[m-a-n-j-u]

Hello Alberto,

Thank you for the advice, it helped! I agree that there was no need to modify the firmware for adding support for AT89 devices.

This problem occurs both when using the official firmware release, as well as firmware built with SDCC. It does not occur when programming PIC controllers, but occurs on AT89S52 as well as AVR (I could only check with ATmega32 at the moment). Sorry I have misquoted on AVRs in my previous post: I had forgotten that I had modified opgui to retry reads. Rarely, ATmega32 does not show any problems (programming and verification succeeds) without any opgui modifications. But most times I either get "Synchronization error" or "Unknown device" with ID 000000.

I'm programming the controllers in-system by connecting to their ICSP headers. I do not know if the circuitry on the target boards is interfering with programming. I'm going to try socketing the controllers directly, once I add sockets to my programmer prototypes.

What I noticed in the log file (Log.txt generated by opgui when "Options-->Log activity" is enabled) is that bufferI[] sometimes contains the contents of the previous response, or in some cases all bytes are 0x00. I saw in the documentation that this is normal behavior when there is no response within the given time. I had observed something similar before my first post also (although not using Log.txt) and tried increasing the delays passed to PacketIO, but that did not help.

The work around I'm using now is to retry certain operations. This work around is enabled only when building with "make RETRIES=1". With this I can successfully program, verify and read-back AT89S52 as well as ATmega32. I have updated the opgui patch from my previous post.

I also observed that WriteATmega() already retries reading a few times when it performs write verification. So I think I must check and address the other problem areas similarly. Currently the work around is inside the PacketIO() function. But once I test more devices, I will move it into device specific algorithms. I will be sourcing a few different AT89 and AVR parts some days later and will post again when I have more updates.

Thank you for all the support.

[Vitor_Boss]

"I'm programming the controllers in-system by connecting to their ICSP headers. I do not know if the circuitry on the target boards is interfering with programming. I'm going to try socketing the controllers directly, once I add sockets to my programmer prototypes."

Try to add more time to power up the entire board, I have the same problems with PIC devices on ICSP.

[Alberto Maccioni]

Delays are (were) a problem under linux, because read() does not wait for a new packet before returning data. So sometimes, if delay(x) is not sufficient, there are problems.
I tried to have the minimum delays that give reliable communications, but of course my test system, although very slow, is not exactly the same as yours, so some issues could happen from time to time.
Anyways, I also introduced a new packet exchange function, PacketIO(), which waits for the proper response also under Linux; it's presently used only in some algorithms; I expect all problems to be solved if you substitute all:
write();
msDelay(#delay);
read();
with:
PacketIO(#delay);