After a thorough investigation, it turns out that the Proteus 8 simulation of the PIC16F84A (and possibly other MCU-s in PIC16 family) has a bug when interpreting the assembly language code, which happens either the source code is put directly in Proteus, or its compiled hex or cof form is read into the device.
THE OBSERVED BUG IS as follows:
-- any setting (BSF) or clearing (BCF) of PORTA pins <3:0> will inadvertently RESET the pin 4 on the same port, that is: RA4 will turn to 0 if it was previously set to 1.
Picture 1 contains the assembly code, where the instruction comments (even of those which are commented out) explain the errors.
For example, if the RA4 is set to 1 (in line 29), and after that the RA3 is either set to 1 or cleared (and in this case it doesn't matter if it was already 0), RA4 will be cleared.
Picture 2 shows the state of the debugging simulation immediately after the instruction BSF PORTA, 4. In the bottom of the window, the binary state of PORTA is displayed, showing that the pin 4 is set: PORTA = 00010000
Picture 3 shows that after the following instruction, BSF PORTA, 3, the pin 3 is set as desired, but also that the pin 4 is cleared by mistake: PORTA = 00001000
The cause is probably the wrong binary mask for the PORTA in the simulation, or the improper logical treatment of the mask and the previous contents of the PORTA.
A FEW MORE OBSERVATIONS
- The same code executed in the MPLAB IDE simulation (MPLAB SIM) runs as expected.
- RA4 pin is of open-drain type, in difference to the pins RA3:RA0, but the error is happening on the logical level of simulator, so the bug has nothing to do with that.
The problem could be solved by setting the RA4 last, that is, after all the RA3:RA0 pins are set or cleared. This further confirms the hint that the problem is somewhere in the handling of the bit mask.
- Has anybody else encountered the same problem?
- Is this bug fixed in the later versions of Proteus 8?