Fail on first access to i2c (SOLVED)

oxo · Joined: 13 Nov 2012 Posts: 219 Location: France

Hi all,

We have a product, many hundreds shipped, all working well.

But some ( cca. 1%) have been locking up on power-up. On investigation it seems to be in the I2C initialisation. Running in the debugger, it's stuck at the #use i2c line.

This is what we have:-

#use i2c(MASTER, I2C1, SLOW, FORCE_HW)

PIC is 18F26K22 and compiler 5.053

Ttelmah · Joined: 11 Mar 2010 Posts: 19540

Look at this:

<http://sfcompiler.co.uk/phpBB3/viewtopic.php?f=3&t=1850>
and:
<http://www.microchip.com/forums/m827704.aspx>

I moved the #USE I2C, so it was after the analog setup, and things then work OK.

It seems to be 'unique' to the 26K22, and 46K22, that the analog setting interferes with the I2C initialisation.....

oxo · Joined: 13 Nov 2012 Posts: 219 Location: France

Thanks for that. I am investigating..

but, I don't use analog on this project, and checking in the debugger, ANSELA , B, C are all zero.

Ttelmah · Joined: 11 Mar 2010 Posts: 19540

Where are they being set low though.
Before or after the I2C initialisation?.

oxo · Joined: 13 Nov 2012 Posts: 219 Location: France

Before. It happens unseen by the debugger on the entry to main()

RF_Developer · Joined: 07 Feb 2011 Posts: 839

oxo · Joined: 13 Nov 2012 Posts: 219 Location: France

Thank you RF, but I don't think that's it because I have a 100 ms delay before initiialisation functions are called.

temtronic · Posted: Thu Jun 02, 2016 5:23 am

Any chance the '1 %' PICs are ALL from the same batch or lot ? I know, like the rest of us you probably didn't record the batch number when units were shipped, sigh.
What about LCD modules? If used on your product, are they all the same ?
Assuming you've got a few 'bad ones' in your hand, look for common 'numbers'. Also try a 1 second 'preINIT' delay. 100ms is not long in the Real World. Change to 1 second, see if they fail. If that 'cures' it at least you KNOW something. It could be a 'slow' power supply, maybe the I2C device is a different batch,??? No one can really say for sure.
Since 99% of them work great, assuming same [identical] code, it has to be a hardware issue. Sadly you could easily spend a week or two getting to the cause. Just write down EVERY possible cause, try a 'cure', WRITE down what happens. That way you won't do the same thing 3 or 4 times then say...hmmm didn't I do this already ? , arrgh !
Good luck
When you find it, POST IT. even if it's a 'silly' thing. BTDT !!

Jay

Ttelmah · Joined: 11 Mar 2010 Posts: 19540

As a comment also, _nothing_ should be 'unseen by the debugger'. Debug on the assembler, not the C program.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

temtronic · Posted: Thu Jun 02, 2016 5:03 pm

You probably shouldn't 'debug' using the 'debugger' as it really isn't the 'real World'. It can easily change fuses, mapping, etc. just to run itself as well as connecting to the PIC. It'll also take 'control' of some features or functions so the PIC won't run properly.
I'd use an LED with a 'blink' function. Cut code like the POST of every PC. Before every major 'event', flash the LED to signal the 'event' is to take place. If, after say the 3rd 'event', you do NOT see the LED flash 4 times then you KNOW where the code is 'hanging' somewhere between #3 and #4 'events'. What you decide on an 'event' is up to you. obvious ones are PIC Init, LCD Init, peripheral Inits, PC comms, etc.

Jay

oxo · Joined: 13 Nov 2012 Posts: 219 Location: France

Ttelmah · Joined: 11 Mar 2010 Posts: 19540

Realistically the first thing to do, is write a minimum program, that has your fuses, and just puts all your chip pins to 'safe' states, then tries to talk to the I2C device only.
If this uses the exact sequence you are using to talk to the device, then you can post it, and also if this behaves differently (or the same), data is gathered.

Now the PIC will only hang on I2C, if the data line pulled low. The obvious suspicion is something like the fuel gauge chip not actually initialising correctly, and the bus is getting hung. This is why the AD has to be 'off' on these lines, since if this is on, a digital 'read' will not see a 'high', so the I2C peripheral, then hangs.
Do you connect to the charge complete pin?.
On your code, do you read the status register before proceeding?.
The latter is important, since the chip will behave differently if it has done what it sees as an 'undervolt recovery'. It is possible that some slight difference in the connection to the sense pin (even something like a different make of capacitor), is resulting in this mode being triggered.

So 'data' please. Smile

oxo · Joined: 13 Nov 2012 Posts: 219 Location: France

"data"

I will do, but unfortunately, the unit has decided to work correctly. I am currently trying to provoke it into misbehaving again.

Your comment about debugging in assembler was very useful. Somehow in recent years I have given up on working at the assembler level. Your kick was most helpful Smile

Ttelmah · Joined: 11 Mar 2010 Posts: 19540

Think what has changed?.

Something like temperature?. Possibly the PIC or the gauge is failing when it is hot/cold?.

Recently had a small batch of PIC24's, that would fail every time if the temperature was above about 24C. The chip was only running a few degrees above ambient, but tried to use it in a warm office, and it'd fail. Put it on the test bench down in the lab, and it'd work every morning....