![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
oxo
Joined: 13 Nov 2012 Posts: 219 Location: France
|
Fail on first access to i2c (SOLVED) |
Posted: Thu Jun 02, 2016 1:47 am |
|
|
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
Last edited by oxo on Tue Aug 02, 2016 4:54 am; edited 1 time in total |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Thu Jun 02, 2016 1:57 am |
|
|
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..... |
|
![](templates/subSilver/images/spacer.gif) |
oxo
Joined: 13 Nov 2012 Posts: 219 Location: France
|
|
Posted: Thu Jun 02, 2016 2:15 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Thu Jun 02, 2016 3:34 am |
|
|
Where are they being set low though.
Before or after the I2C initialisation?. |
|
![](templates/subSilver/images/spacer.gif) |
oxo
Joined: 13 Nov 2012 Posts: 219 Location: France
|
|
Posted: Thu Jun 02, 2016 3:37 am |
|
|
Before. It happens unseen by the debugger on the entry to main() |
|
![](templates/subSilver/images/spacer.gif) |
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
Re: Fail on first access to i2c |
Posted: Thu Jun 02, 2016 4:00 am |
|
|
oxo wrote: | many hundreds shipped, all working well. |
...Except the 1% that don't.
Beware, debugging startup problems like this is difficult. Debugging can be misleading in cases like this. Why? Because a start-up when debugging is very different from a normal power-up. All debugger starts are warm-starts: the oscillator is running normally and fully stabilised, the power voltage is also normal and not ramping up.
In real power-ups, the processor core often runs at quite a low voltage. The peripherals (I've had particular trouble with the CAN hardware) may not be running/runnable when the processor has just started. To get round this I use the LVdetect hardware available on many PICs to avoid initialising the CAN peripheral until I know the power is good.
The clock start-up is another issue. In a real power-up, on many processors the core will not be running from the main oscillator, and therefore not at the expected speed, for hundreds, if not thousands of instructions, and often well into user code. This can also can confusion and odd behaviour.
The code to get round this varies from processor to processor. This is the code I used on an 18F4580:
Code: | // This is here to ensure we get normal timing now on.
// Wait for the crystal oscillator, to stabilise. Before it does, we're on the default
// 1MHz internal clock which rather confuses things.
while ((setup_oscillator() & OSC_STATE_STABLE) == 0); |
I don't use I2C very often, preferring SPI for local comms, CAN for system-wide comms, and serial (including USB via USB-serial chips, and RS485, often MODBUS) for external communications. I don't know whether the internal I2C peripheral suffers voltage and clock start-up issues.
This sort of thing simply doesn't happen on warm starts, such as when debugging. |
|
![](templates/subSilver/images/spacer.gif) |
oxo
Joined: 13 Nov 2012 Posts: 219 Location: France
|
|
Posted: Thu Jun 02, 2016 4:05 am |
|
|
Thank you RF, but I don't think that's it because I have a 100 ms delay before initiialisation functions are called. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9174 Location: Greensville,Ontario
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Thu Jun 02, 2016 7:12 am |
|
|
As a comment also, _nothing_ should be 'unseen by the debugger'. Debug on the assembler, not the C program. |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu Jun 02, 2016 4:44 pm |
|
|
Quote: | But some ( cca. 1%) have been locking up on power-up |
What's the manufacturer and part number of the i2c chip that you're using ? |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9174 Location: Greensville,Ontario
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
oxo
Joined: 13 Nov 2012 Posts: 219 Location: France
|
|
Posted: Thu Jun 02, 2016 11:52 pm |
|
|
PCM programmer wrote: | Quote: | But some ( cca. 1%) have been locking up on power-up |
What's the manufacturer and part number of the i2c chip that you're using ? |
LTC2941-1 battery gas gauge. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Fri Jun 03, 2016 1:09 am |
|
|
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](images/smiles/icon_smile.gif) |
|
![](templates/subSilver/images/spacer.gif) |
oxo
Joined: 13 Nov 2012 Posts: 219 Location: France
|
|
Posted: Fri Jun 03, 2016 1:14 am |
|
|
"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](images/smiles/icon_smile.gif) |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Fri Jun 03, 2016 2:44 am |
|
|
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.... |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|