16F737 port A bug?

[medelec35]

Not sure if this is a bug, or I'm missing something very basic?
This is what I want to happen. From start, port A0 on all the time (not to go off at all).
After 2 seconds, port A2 enabled as a low output
Finally after another 2 seconds, port A2 to go high.
Sounds very simple.
Ran flowcode simulation....perfect.
Ran on real hardware and on a different simulator (encase chip was faulty) and result is not as expected:
A0 goes high for 2 seconds,
then A0 goes low (when A2 is set to low)
then after 2 seconds A2 goes high
A0 stays off.
Strange why A0 goes off ,when there is not a function A0>0. Any ideas please?
All I can see is at address 0x37 FB is being 'AND' with 1, I am assuming to mask bits, but result is 0, going back into port A, which is setting port A0 to 0.

[Benj]

Hello Medelec

I have had a quick look around and have found some comments such as

-- - Procedures for shadowing of ports and pins
-- to circumvent the read-modify-write problem.

when using this device.

I've also found out there is an oscillator problem on this device but this is a different matter.
http://www.microchip.com/forums/tm.aspx ... 37&#173242

The C code generated by Flowcode looks correct to me maybe you could try the raw C code in the flowcode C code icons and see where the problem is apprearing.

//Switch on A0
trisa = trisa & 0xfe;
porta = (porta & 0xfe) | 0x01;

//Switch off A2
trisa = trisa & 0xfb;
porta = porta & 0xfb;

//Switch on A2
trisa = trisa & 0xfb;
porta = (porta & 0xfb) | 0x04;

[medelec35]

Thanks Ben.
Will give that a try.
Strange one this.
If C code looks correct, then perhaps problem is induced by complier. I will change targets and post if working or not.

[medelec35]

More I look into it more confusing it gets.
Tried your C code suggestion, and does not work.
Even If a port A0 was set at 1 just after 0 to A2, port A0 still goes and stays low.

Changed target to 16F88, and is working as expected on external sim.
Looked at assembly code generated by both f737 and f88. both are 'AND'ing FB with gbl_porta = 1. So running simulator:
With F88 result = 1
Strange thing is however with F737 result = 0. I would of expected 0xFB AND 0x1 = 1
Since these results are using an external simulator loaded with hex compiled files and Simulation results are same as hardware, the hardware can be eliminated.

[Steve]

Since these results are using an external simulator loaded with hex compiled files and Simulation results are same as hardware, the hardware can be eliminated.

...unless the external simulator knows about a bug in the silicon of that chip!

This does seem a strange problem. Have you tried producing code with the HI-TECH compiler instead? Another thing to look at in embedding the Assembly to do this into the code.

[medelec35]

...unless the external simulator knows about a bug in the silicon of that chip!

Dam. Simulator must of overheard me talking about the hardware problem, and decided to play tricks on me!
Thanks Steve.

[Benj]

This certainly is odd.

Another thing you could try is to do this using C code.

trisa = trisa & 0xFA;
st_bit(porta, 0);
delay_s(1);
cl_bit(porta, 2);
delay_s(1);
st_bit(porta, 2);

If this also fails to work then you could also try this

trisa = trisa & 0xFA;
porta = 1;
delay_s(1);
porta = 1;
delay_s(1);
porta = 5;

This last one will confirm if it is a read modify write problem.

I would also try the HITECH compiler using the standard Flowcode icons to see what this does.

[medelec35]

Thanks ben will try all what you have suggested.
Still same using hitec compiler.
BTW using hitec to compile other software gave numerous errors. You interested in me posting errors?
I'm not overly bothered, since same programs compile fine with boost C.

[Steve]

Yes - please post details of HI-TECh compilation errors in a separate thread.