Output Issues with individual Port addressing

[chipfryer27]

Hi

I was getting strange results within a program so decided to investigate further, briefly hardware wasn't doing as it should.

I created a breakout board and connected it to Port C of an EB-006-09 fitted with a 16f877a and in Flowcode using 5mm_Led Outputs created the following which is mimicked in hardware.

Port C0 = Clip-3 (red led)
Port C1 = Clip-2 (orange led)
Port C2 = Clip-1 (green led)

My program first switches off all on Port C, then it loops three times flashing all led's on/off. This is fine. It then illuminates Clip-1, waits, illuminates Clip-2, waits and then illuminates Clip-3. So basically after flashing three times it illuminates each led in turn and I end up with all three led's on.

Perfect in simulation and in hardware.
Program Test-1 is my program.

Test-1.fcfx

(9.77 KiB) Downloaded 156 times

In this program you can see that I am outputting exactly which Ports I want On by sending the corresponding value to the Port (e.g. 4 / 6 / 7 which sets C2 / C2 and C1 / C2, C1 and C0 = On respectively).

However if I then change my output method to addressing each bit individually I get funny results.
Please see Program Test-2

Test-2.fcfx

(10.2 KiB) Downloaded 152 times

In this program I set each bit of Port-C individually.
After flashing OK I then send a value of "1" to Single Bit 2, then to Single Bit 1 and finally to Single Bit 0.
This should have the same results as Test-1 but this time after I send "1" to Single Bit 1, as well as illuminating the LED attached to Bit 1 it switches Bit 2 Off. When I send "1" to Single Bit 0 it illuminates alongside Bit 1 but Bit 2 stays Off.

I then tried using the Call Component macros.
Please see Test-3

Test-3.fcfx

(9.78 KiB) Downloaded 150 times

In this I switch Led-Clips 1 to 3 On individually but I get the same results as in Test-2. When I switch on Led Clip-2, it comes On but switches Clip-1 Off. When I then switch on Clip-3 it comes On alongside Clip-2 but Clip-1 remains Off.

I see this in hardware so thought perhaps the chip was a bit iffy however I tried the above in three different chips with the exact same results. If I output anything other than the exact Port settings I need, then things go astray.

Incidentally if I send 255 and use masking (2/1/0) everything is OK.

Anybody got any idea of what I'm doing wrong?
Regards

[chipfryer27]

Hi

Further to above I have discovered that the issue seems limited to the 16F877A (or at least my stock of) when using the component macro.

To recap, the three leds attached to port C should flash three times then illuminate one at a time so that at the end all three are lit. This works fine in simulation.

When I compile to a 16F877A chip with LEDs attached to Port C

877A-Test.fcfx

(10.24 KiB) Downloaded 151 times

The program flashes the leds three times but when I switch on sequentially (Clip-1, Clip-2, Clip-3), when Clip-2 illuminates Clip-1 goes out.

When I change the target to a 16F1939 the problem disappears, it works fine in hardware.

1939-Test.fcfx

(10.29 KiB) Downloaded 155 times

You might think that I have a dodgy 877A, however I have three of them and they all do the same. If I don't use the component macro then I can control the port fine by sending the required binary to the port (e.g. 1/3/7).

I changed the components to 3mm LED but it still has issues when targeting a 877A

877A-Test_3mm.fcfx

(10.35 KiB) Downloaded 146 times

Does anyone out there have a 16F877A that they could try as I find it a bit strange that all three of mine behave in the same stupid way.
Regards

[Benj]

Hello,

Do you have anything connected to the pins. It seems strange I've not come across this recently.

What seems to be happening is this.

First you set bit 2 of port c and the portc register gets this value

portc = portc | (1<<2) = 0x04

Then when you set bit 1 of port c the reading of the portc register fails to detect the logic 1 on the pin C2.

portc = portc | (1<<1) = 0x02 and not 0x06

Are you driving a large current on the pin or anything else which may be forcing the readback to see a 0 instead of the expected 1?

The 16F1939 may not have the same problem as it has seperate Port and Latch registers and the command is slightly different. The latch register is what the port output value should be and not what is directly read back from the pins. e.g. it's more reliable under high load.

portc = latc | (1<<2) = 0x04
portc = latc | (1<<1) = 0x06

[chipfryer27]

Benj

Thank you so much, that was exactly it.

I had some generic led's connected to the port via whatever limiting resistors were at hand (all supposed to be the same value) but on further inspection the troublesome output had a resistor of value way below its markings. Replacing the resistor brought it all back to life.

I was using these leds on the port to help with some other issues (most likely the software doing exactly as it has been told to do versus what I thought I told it to do) and it was rather confusing to say the least.

Thanks again for the help which as always is much appreciated.

Regards

[Benj]

Excellent, glad to be of service. Thanks for letting us know.

Certainly is a headscratcher when that sort of thing starts happening