PIC16F1847 wont work on crystal oscilator (with I2C)

[dyeatman]

The published specs are:

[temtronic]

Yes, I read the electrical specs of the BNO080.... Vout is 90% of VDDIO which means .9* 3.63, so Vhigh is 3.3 volts.
What's unclear is does the 'module' contain additional 'logic level' conversion chip ? Maybe it does ? need to see schematic of the module...

If using PIC's I2C pins, Vhi is .7* VDD so .7*5=3.5

Close, but not 100% .Maybe sensor puts out 3.4, PIC is OK with 3.4, so may work but I wouldn't trust it. Change room temperature, turn on an LED, oopsy... 'it doesn't work'.....

Now that PIC will work at 3 volts,32MHz so that's how I'd design/build the unit.

[gjs_rsdi]

From the data sheet:

[temtronic]

hmm.. since Mr T proved the PIC works fine with intrc and xtal ,using EEPROM and I2C scanner program and you say the compass operates fine.......

....perhaps there's a 'setup' requirement of the compass chip that's met with the internal RC and not the xtal/caps clock ?

maybe code so...

PIC gets power
setup serial and I2C
delay 500ms
blink an LED
reset the I2C bus
send 'reset' the compass
delay 100ms
blink an LED
then execute main()

I suspect the compass is getting 'locked' due to some timing issue or invalid set of pulses to it.

[Ttelmah]

Can I suggest you add SMBUS to the I2C setup. This reduces the voltage
the I2C will accept as a high. Safer for a 3.3v device. I was using a 5v
EEPROM for my test.

Also, I'm scared by one erratum on your chip. It has a problem that can
result in the chip not waking with a crystal, if the crystal is slow to start.
Tell us what the actual crystal you have is, how it is wired, and what
loading capacitors you are using. It may be that your crystal is one that
takes too long to start and hence your chip does not run with your crystal.
Any chance you have a different one you could try?.

[temtronic]

read some more stuff of the net and the BNO080 device in the compass module does have some 'power up' specs
The OP does say xtal does the 1Hz LED pgm, so on the surface not a xtal problem.

Since the only hardware change is the PIC clock, my gut says 'timing'. Maybe the compass module gets confused,so that's why I suggested a proper I2C reset,wait a bit, then access the compass.

[Ttelmah]

I have to ask a couple of thingsL
Why not just use software I2C?. You are only running at 100KHz, software
will do that easily. Also using software I2C, you can just use pins with
TTL input levels, and it won't then mind 3.3v signalling.
If you must use hardware, then try using I2C2. It would tell us a lot
about what is actually happening.
Also what is the decoupling on the chip?. The crystal is more fussy about
decoupling than the internal oscillator. I'm wondering if when the chip tries
to signal on the I2C is is causing a glitch on the supply.

[temtronic]

I'm pretty sure that PIC will run at 3v3, so simple test...run at 3v3 and see what happens ??

I don't know about the 'startup' time difference between using the internal RC vs a real xtal/caps but....

[gjs_rsdi]

Hi Ttelmah

I am working with this PIC16F1847 for many years but first time with I2C.
I used PIC18F26K22 for the CMPS14 with I2C also I2C for EEPROM to other PIC's (with your help in the past) always 5V with 2.2K resistors on SDA and SCL

I will try to answer one by one:
I have 3 PCB's, 3 PIC16F1847, all have the same problem with I2C.
To use I2C2 will have to make new PCB. Will check if I can use hardware UART on other pins if I use I2C2.
I have other functions working with interrupts, this why I don't want to use the software I2C.
The decoupling on all the chips are 100nF capacitors, good quality.
I check the supply voltage with oscilloscop, found no glich on the power supply
I have powerup timer enabled.
Can you write me how to add SMBUS? never done it

Hi Temtronic

I had no any issue with the CMPS14 get confused. It gives always correct data.
I am waiting 100ms between asking for new message

Best wishes
Joe

[Ttelmah]

On I2C, use of interrupts for other interfaces makes no difference. Interrupts
are only used for I2C receive. For transmit, there is no advantage to using
the hardware, except if you are using speeds, above those the software can
do. Since I2C is a master timed interface, if there is a pause in the
transmission, while an interrupt is serviced, it makes no difference at all.

#use I2C(MASTER, SLOW=100000, I2C1, SMBUS, STREAM=I2CPORT)

[gjs_rsdi]

Thank you for the prompt answer Ttelmah

I am out of office, will test again tomorrow

Best wishes
Joe

[gjs_rsdi]

Hi

I added to the I2C

[Ttelmah]

and what happens when you use software I2C?.

Mys suspicion is that something about the sequencing of the signals on
your board is resulting in the I2C peripheral getting hung when running
off the crystal.

[temtronic]

hmm...
another test to try...
add a 2nd I2C device, run the I2C Scanner program. does it return BOTH devices ?