Bug in 18X I2C ???

I use 18X version 8.6 connect to PCF8574AP. Unfortunately, I can't get it work. After I change to 28X using the same code. It works well.

I use my scope to check the signal. It is not relative to the noise problem. Maybe the clock pulse of SCL does not match the SDA. When I switch on and off for about 10 times. It works for one time.

I suspect it fails because of the internal OSC, it may require to fine tune. Do you have any idea? If I use 28X I don't need the I/O expander because it has enough I/O pins.

Here is the source for your reference:

pause 2000
i2cslave %01110000, i2cslow, i2cbyte
writei2c 0,(%10101010)

In this type of communication system the resonator tolerance is irrelevant as the PICAXE generates the clock signal itself, and on the 18X the speed will always be less than the maximum allowed by the i2c protocol. So have another look at your wiring for the issue, you nust be changing hardware setup also when moving from 18X to 28X...

18X uses 16F88. It does not have a MSSP module. Does it affect the I2C performance?

We have used this chip before with an 18X and so know that it works correctly with the 18X! How is your 18X circuit configured - check the pull ups etc!?

Note you are also outputting two write bytes - 0 then %10101010. This is not normal for this chip. Your write should be without an address byte. You should also only issue the i2cslave command once, at the very start of your program.

i2cslave %01110000, i2cslow, i2cbyte
pause 2000
writei2c (%10101010)

Thanks for your reply but it does not work. I don't know why when I add two 4.7k pull up resistors in the I2c bus, the (pin 6) output 0 is high. I don't connect anything on pin6.

I am pretty sure this is the bug in 18X. There is no reason to pull up (pin 6) output 0 when I use i2c command. I check my circuit board without any problem because I success to use 16F628A with Proton complier.

Could you please check this firmware version? Maybe the problem is only in a particular firmware.

The following is my source code in Proton basic plus. I use the same pin layout as 18X. So, the problem should be in 18X.


DEVICE 16f628a
declare xtal=4
declare sda_pin portb.1
declare scl_pin portb.4
declare slow_bus 0

bstart
busout %01110000
busout %10101010
bstop

There is nothing in the 18X firmware for the i2c command that will affect output 0.

So this leaves two options:
1) you have a faulty hardware setup
2) you have a 18X that has been internally damaged in some way.

Have you actually tried with more than one 18X, or are you always testing with the same (possibly damaged) chip?

Yes, this one may be damage but I use another brand new chip. It doesn't work either. Thank's mate. I give up.

I remember a problem I had when following the documentation and using an RTC.

The SCL and SDA lines were reversed on the data sheet. I'm a bit busy at the moment, but I think you might find some help along those lines.

Ivan

Thanks for your reply. I have tried your method but not success. I am now using Proton+ Basic which can program any pin as I2C communication port.

If the 18X cannot use I2C I may consider to buy 18A. The poor thing is they don’t really investigate the bug in 18X.

You seem to be mixing apples and oranges.

There is no "bug" in the 18X implementation of I2C. The PICAXE chips have a built-in interpreter for the tokenized code generated by the Rev-Ed compiler. That built-in interpreter limits which pins can be used for various functions. If you want to use the PICAXE chip and the Rev-Ed IDE, then you must accept those limits. If the documents say the 18X only provides PWM or I2C on a specific pin, then that's the only pin that can be used. Your program will *not* change what's in the on-chip interpreter.

The Proton+ compiler is for the blank chips (12Fxxx, 16Fxxx) and is *not* for use with the PICAXE chips. You trade more complete access to the chip's functionality (using any of several pins for some functions) for more a more complex development environment.

John

To reinforce what thelabwiz is saying: From your original post:<code><pre><font size=2 face='Courier'>
pause 2000
i2cslave %01110000, i2cslow, i2cbyte
writei2c 0,(%10101010)
</font></pre></code>
....will <i>not </i> work on the 18X.

Pin 0 (leg 6) on the 18X is not built for i2c. The function is only available on Pin 1 (leg 7) and Pin 4 (leg 10)

Refer to the Getting Started Manual 1, page 18

I must admit that I'm confused by this thread.

If I understand it, cylau is wiring up the 18X correctly for SCL and SDA, but (apparently) the i2c doesn't work. And when his pull-up resistors are connected to SCL/SDA then his Output 0 goes high.

I've tried to duplicate his fault but cannot. I don't get the problems he's describing.

However, Pete, I don't THINK he is implying that 'Output 0' (pin/leg 6) is used for i2c but just that (for him) it goes high. I THINK he's using the term &quot;pullup&quot; to suggest it goes high rather than a physical pullup resistor - read cylau's 3rd post. Anyway, it doesn't go high for me and the SCL/SDA outputs are fine (though I wasn't using a PCF8574AP I admit).

And his Proton code implies he's using the same physical pins (or 'legs' as some of you quaintly say).

His 18X problem suggests (to me) that he accidentally connected his SDA &amp; pull-up line to Output0 which would explain why it goes high when connecting pull-up resistors, but he says all connections were fine and dandy. Like a good loudspeaker, I am baffled.

One other thing confuse me:
If you have to use 'writei2c (%10101010)' for 18X + PCF8574 , then how come 'writei2c 0,(%10101010)' apparently works on the 28X? I have no experience of either 28X or PCF8574 but I'd love to know.


Multiple confusion is sending me towards the kettle, good luck.

<BLOCKQUOTE><font size=1 face=arial>quote:<hr height=1 noshade>how come 'writei2c 0,(%10101010)' apparently works on the 28X? <hr height=1 noshade></BLOCKQUOTE></font><font face='Verdana, Arial, Helvetica' size=2>

it would just briefly switch all the outputs off and then back to the desired state - as you are basically sending the two bytes %0000000 and then %10101010 to the pins on this particular chip. It would happen so quick you wouldn't actually notice on LED type test setups, but it is still wrong and would give issues on fast logic based systems.

The output0 issue definately implies a wiring issue somewhere. Proton wouldn't automatically make the same pins input/outputs as PICAXE does, so an incorrect wiring on, say, PICAXE output0 may not matter with Proton because this pin wouldn't be set as an output by default anyway!

Edited by - Technical on 11/10/2006 11:03:49

I am not going to change the pin function. As describe, pin7 is sda and pin 10 is scl. They both have 4.7k pull up resistor. 18X does not have a MSSP module, so the communication relies on the firmware. It is possible to have bugs in the firmware.

This is a simple circuit. I don&#8217;t think I make mistakes on this circuit. Moreover, I can use Proton+ in this board. Second, I don&#8217;t think this command is wrong because the same command I can use in 28X. 'writei2c 0,(%10101010)&#8217;

This command I copy from someone&#8217;s program in the net. It sets all the pins to zero first and set (on off on off on off &#8230. I buy the chips from Australia and some from US as well. They have the same problem.

Output 0 (pin 6) is unstable. Sometimes it goes up by itself. Firstly, I thought this chip is faulty but when I flash other program to the chip without the I2C command. It works perfect.

I use PCF8574AP is for testing purpose. I originally use PICAXE to control an audio chip DSD1794. I find that DSD1794 is un-controllable then I use PCF8574 for testing. The board has the high end regulated power supply. (LT1084 and LT323). If someone says 18X is okay then I try to add more filter cap to test once again.

<i>18X does not have a MSSP module, so the communication relies on the firmware. </i>

The 18X (16F88) has an SSP module and, unless I am very much mistaken, the I2C interface is through that on-chip hardware.

Conversely, according to the datasheet for the 16F628A you are using, that doesn't have any I2C hardware and would therefore appear to be entirely software driven when using Proton+ generated code.

You say that the 'writei2c 0,(%10101010)' command works on the 28X. As Technical has said, you are not sending the equivalent of your Proton+ code but ...<code><pre><font size=2 face='Courier'>bstart
busout %01110000
busout %00000000 &lt;--- Extra byte here
busout %10101010
bstop </font></pre></code> or something like that. I cannot however see why that would work on a 28X but not on an 18X, although it could be a timing issue. Does 'writei2c (%10101010)' work on the 28X ?

You also say you had the DSD1794 working. Is that with the 18X ?

It seems to me that the problem only occurs with the PCF8574 chip. Try removing the physical chip and running your code. Does Out 0 ( leg 6 ) still go high without being instructed to ? What happens when you send other values ?

Also, what exactly do you have connected to Out 0 ( leg 6 ) ? If only observed during debugging, what voltage does it go to ?

Edited by - hippy on 11/10/2006 12:17:28

Thanks for explanation. This is SO wierd. A real head-scratching problem. My pin6(Out0) is fine running an i2c prog. In the 3 18Xs I tried, I don't have any &quot;instability&quot;.

I have never heard it reported before so a bug problem is unlikely. Loads of people use the i2c and I'm sure an issue would have cropped up years ago.

I always get very worried if I have a problem and no-one else does. And a current thread on 08M tunes had ol' Southernbob cussing the PICAXE and saying everything was double-checked - then...

Aside from the wiring checks which have obviously been double-checked ad nauseum, may I ask just one thing? After you have downloaded the PICAXE prog and removed the cable etc, is there anything connected to the programming Serial In (pin3)?

For your Proton stuff are you using the 16F88?

Edited by - Dippy on 11/10/2006 12:55:05

Tonight I build a new board, add lots of regulated caps to prove the bug in 18X. I use a brand new 18X, PCF8574A and 16F628A.

1) Proton+ 16F628A, program below.

Device 16F628A
Declare XTAL=4
Declare SDA_PIN PORTB.1
Declare SCL_PIN PORTB.4
Declare SLOW_BUS 0

DelayMS 2000
BStart
BusOut %01110000
DelayMS 2000
BusOut %10101010
BStop

I find that even I submit the Bstop command, the address and data repeats in the I2C bus looks like a loop.

2) 18X, problem below

main:
pause 2000
i2cslave %01110000, i2cslow, i2cbyte
pause 2000
writei2c (%10101010)
goto main


I use a loop to imitate the result but not success. I can catch only two triggers. One is rubbish and one looks like address. If I change the writei2c command to writei2c 0,(%10101010). I catch one rubbish trigger, and the address repeated but the data is missing.

Please download the graph that I capture from scope. &#8220;http://audio.hobby-site.com/18x.doc&#8221; . I did more than a customer. I should have some chips for free.

Try moving your i2cslave %01110000, i2cslow, i2cbyte to the top:-

i2cslave %01110000, i2cslow, i2cbyte
main:
pause 2000
writei2c (%10101010)
goto main

Using this I got almost exactly the same scope trace as your Proton example, except I think one of your traces is AC coupled so mine looked better.

And no twitching of pin6(out 0) either.

PS: You say &quot;I find that even I submit the Bstop command, the address and data repeats in the I2C bus looks like a loop.&quot;
Apologies, I really don't understand that.

Edited by - Dippy on 12/10/2006 09:52:20

You are not exactly comparing like program for like!

We have never used Proton, but to get a similar program for each chip you should do something like:

main:
DelayMS 2000
BStart
BusOut %01110000
BusOut %10101010
BStop
goto main

as the PICAXE writei2c command does this
- start, slave addresss byte, data byte, stop

so picaxe would be

i2cslave %01110000, i2cslow, i2cbyte
main:
pause 2000
writei2c (%10101010)
goto main

Your original proton program is not really correct for i2c communication. You shouldn't have a 2 second gap between slave address and data! The PICAXE i2c command sends the two bytes directly one after the other, which is why you are not catching it on the scope.

Note also that you should never use the i2cslave command within the loop. Its purpose is purely to preload the PICAXE internal memory with the slave address and set the pins in the correct state for PICAXE communication.

The actual slave address is transmitted automatically by the PICAXE during the readi2c or writei2c command.

By regularly repeating the i2cslave command you will be constantly refreshing the state of the i/o pins, which is incorrect and may cause issues.

Could that explain why he had a 'funny' with pin6 (Out0)?

No. It shouldn't have any effect on output0. And no-one else in several years of use has had this either!

The main issue seems to be a complete lack of understanding on how the i2c system works under the PICAXE system. For instance his word document states 'rubbish' beside the trace for the i2cslave command, when in actually fact the trace is perfect - setting up the i2c bus ready for i2c communications. There won't be a slave address trace until the writei2c command is issued and, wow, the slave address trace is clearly shown in his second diagram, exactly where and as it should be!

Yes, I had no problems when testing either.

<i>I find that even I submit the Bstop command, the address and data repeats in the I2C bus </i>

I'll guess you mean 'omit' - That is most likely because the 'bstart' ensures the I2C bus lines are brought to the levels they need to be in order to initiate an I2C Start Command, which in itself is the same as issuing an explicit 'bstop' command earlier. You would have to examine the actual code generated from the Proton+ compiler to see exactly what it was doing with the I2C pins.

<i>I did more than a customer. I should have some chips for free. </i>

Debugging a problem is a part of everyday life in the software and electrical engineering industry, and it could be said that those who had no reason to help but through generosity have done so gave even more in doing that.

It isn't unreasonable that those who identify bugs and faults in products are acknowledged or 'rewarded' for doing so, and I am sure that any faulty product so identified would be replaced free of charge at least. For that, a bug would have to be identified and be shown to reproducible on hardware other than your own, and that has not been the case so far.

Conversely though, if the problem is found to be of your own making or error, what do those who have tried to help or do solve your problem get in return for all the effort they have put in ?

This forum is of a 'give and take' nature where people collectively help each other identify and resolve problems when they can, and issues of faulty product and compensation would be best dealt with by direct contact with Rev-Ed as manuafcturer rather than through this forum, although I do not believe you have proven the product fault yet.

With respect to identifying the problem and solving it, I asked a number of questions earlier ( bottom of page 1 ). It would really help if you could answer those, as it will help those who are trying to help you.

Having made changes as a result of this discussion, can you confirm what does and does not work now with the 18X. Particularly, is Out 0 still going high when it should not, and do other I2C devices work on the bus ?

i2cslave %01110000, i2cslow, i2cbyte
main:
pause 2000
writei2c (%10101010)
goto main

The figures are in &#8220;http://audio.hobby-site.com/18x2.doc&#8221;
When I use this code I can have two trigger only. One is the trace signal and one is the address signal in figure 1. I can&#8217;t find the data %10101010 in the scope. Even this is a loop, I can&#8217;t find the program resend the data.

In Proton+, the I2C statement not using a loop (BSTART BOUT BOUT BSTOP), I find the address and data keep resent in the I2C bus. So, I use a loop in PICAXE but not in Proton+.

The main point is not compare these two programs are equivalent. I just want to make 18X work.

If I change the program as follow:

i2cslave %01110000, i2cslow, i2cbyte
pause 2000
writei2c (%10101010)

I find the address signal keep resend in the I2C bus but the data still missing. This is funny. When I use loop only catch one trigger. Without using loop, the result looks like a loop.

The Output0 pin is unstable in this program. When trigger on SCL pin, the Output 0 is high. See Figure 2. Green line is the Output 0 (pin 6). Yellow line is the SCL pin. Pin 6 is float not connect to any pull up/down resistor. Output 0 goes down after a few ms.

I want to understand more on the PICAXE.

The first scenario:
PICAXE is a boot loader. The complier is in the PC. It flashes the HEX code to the chip.

The second scenario:
The program flashes the basic code. The PICAXE can understand basic. So, PICAXE is an interpreter.

If the first scenario is true, I would like to try another computer. I suspect some problems in the PC program. My computer cannot update to the beta 5.0. When the program starts, I see the about dialog and hear a ding sound then the program stop. I see a message box behind the About dialog but can't see the message. I reinstall the program but the problem still exists.

Your trace shows the output0 as taking about 0.2mS to transition. If there is no external connection then it can only be concluded that it is in a high impedance state. (or the internal connection is blown).
This would suggest that either your reset is being activated (floating?) or serin is being activated, (no download circuit?).
Double check both of these connections.

We might be getting somewhere.

Firstly your green trace ( &quot;trigger&quot; ) is nowhere near as clean as the yellow trace nor is it switching rail to rail. That may be your probes needing adjustment, you may have &quot;AC&quot; selected as thought earlier, or it may be indicative of some wiring fault, a short to some other component.

Although you don't tell your Proton+ code to loop, you don't appear to tell the code to stop either, so the PICmicro is likely to continue executing after 'bstop', run through NOP's and then wrapround to the start of code and begin to execute again, thus actually looping. The other possibility is that the PICmicro is reseting and starting execution again.

Comparing your 18x.doc with 18x2.doc, the same code now appears to be producing a different result, address plus no data this time. That could be significant.

It also appears that you are saying that if there is no loop in the 18X code, the code appears to loop. That suggests that the PICAXE is reseting, because it would not otherwise loop. If the reset is happening after address is sent but before data is sent that could explain why no data is seen.

With respect to Out 0 ( 18x2.doc ) that goes high after some I2C bus execution. That could be caused by some effect of what has been sent, possibly by a reset. If Out 0 were held low, externally pulling it high would produce a high current condition which could damage the pin. In 18x2.doc the rise time of Out 0 is very slow, so it could be that Out 0 is becoming an input as a result of reset and is then quickly floating high being pulled up by an external source. When an actual output, it is pulling the external influencing high signal low. This would be the case if Out 0 had a pull-up to +V or other high signal.

You say that Out 0 then goes low after a few mS. That could be the PICAXE coming out of reset, making Out 0 an output and set low. Out 0 may also become an input for a brief period when the download mode is entered but I am not sure of that.

Yes the PICAXE is an interpeter. The Basic code is converted to tokens not to any .HEX machine code.

As to the problem with the latest editor I cannot help there. Maybe someone else knows a trick to get a messagebox to appear when a top-most window stops and has lost focus ?

With what you've given us here, my suspicion is that the PICAXE is either going into reset or entering its download mode. Ensure that you do have a 4K7 pull-up to +V from Leg 4 and that the 10K/22K download interface is connected to Leg 3 or that leg is pulled to 0V via a 10K. I would recommend uninstalling the latest Programming Editor and re-installing the previous version which did work, and have a look at both Leg 3 and Leg 4 with your scope to see if there is any activity. After powering up, during normal operation, Leg 3 should always be 0V, Leg 4 should always be +V.

I would also recommend that you check or adjust your scope or settings so that both probes give the same readings from the same signal. A short PICAXE program which toggles an I/O line should give you a nice, clean 0V/+V square wave to work with.

As to why behaviour seems less than random as might be expected for reseting, this could be &quot;Sod's Law&quot; ( nothing behaves as it would be expected to ) or the I2C transmission has a subtle effect which is enough to provoke a reset.

We agree with Hippy. The only logical explanation is that when you are sending out something on the i2c bus, your whole system is resetting the PIC. That would also explain the repeated signals from the Proton chip.

Output0 would also then momentarily flash when the chip resets. In fact, all the outputs could momentarily flash.

So we are back to a hardware issue on your system. Have you tried removing the chip on the i2c bus and replacing with something simple like a 2LC16B eeprom. This would help you to find the mistake - if the system no longer crashes the fault is likely to be in the output stage of the system. If the system still fails with the eeprom it is likely to be in the PICAXE side of the circuit.

And, as asked two days ago; what happens when you run the code but the I2C chip is removed from the system entirely ?

Has the 18X worked with other I2C devices ?

Circuit diagram would be a start.

Sorry for my late reply. I am busy in this week. I try to connect a 24LC256 EEPROM tonight. Wonderful, It works!

So, What is the problem? Do you think that 18X has the compatible problem?


The following is my code.

' 18X connect to 24LC256

low 3 ' disable WP pin
i2cslave %10100000, i2cslow, i2cword
writei2c 0,(&quot;hello&quot
pause 10
readi2c 0,(b0,b1,b2,b3,b4)
debug b0

<i>So, What is the problem? Do you think that 18X has the compatible problem? </i>

No, I'd say the PICAXE was just fine, and the problem lies somewhere else, with some interaction caused when the problematic I2C device is used. Either a circuit short, or other wiring issue, or a collapsing power supply, or any of the things already mentioned earlier.

I agree with Hippy. There is no evidence of any problem with the 18X but your traces do indicate a circuit problem as described earlier.

I don&#8217;t really agree with that. To sum up, under the same condition which means using the same circuit board, power supply and PCF8574, 18X cannot control PCF8574 and DSD1794 but other PIC chip using the same pin configuration do. 18X can control EEPROM 24LC256.

The only difference is the writei2c command. 24LC256 uses the command &#8220;writei2c &lt;start address&gt;,(data)&#8221; but PCF8574 and DSD1794 needs only &#8220;writei2c (data)&#8221;.

May be the problem is in the &#8220;writei2c (data)&#8221; command. Actually, refer to the document, I can only find &#8220;writei2c &lt;start address&gt;,(data)&#8221;. So, &#8220;writei2c (data)&#8221; may not fully test.

Can you give me some examples that 18X can control some I2C device that uses &#8220;writei2c (data)&#8221; format?

We're finally bored with this thread and the constant, clearly incorrect, accusations that there is a bug with i2c.

There is clearly a fault in your circuit, even the other system constantly resets as you deseribe yourself - constantly sending out i2c signals when the program only has a single set of commands in it not in a loop!

The writei2c single command was adding in to the firmware at users request. It has been fully tested and works correctly.

Thread closed.

Thread Closed