View previous topic :: View next topic |
Author |
Message |
TYDOM78
Joined: 10 Dec 2024 Posts: 5
|
PIC16F1459 - I2C is not responding |
Posted: Tue Dec 10, 2024 12:04 pm |
|
|
Hello PICMasters.
It's been a minute since I left the landscape of the CCS forum.
I've been busy with hardware design for the past 5 years and haven't spent much time coding with PICs.
I'm back with what may be some silly questions and looking for help.
Here's the skinny:
Using freshly purchased 5.118 C workshop compiler.
I have a PIC16F1459 that won't respond to I2C commands.
I am using external 10k pull up resistors on SDA and SCL lines.
Using the wizard tool I have setup the following code:
Code: |
#include <I2CTEST.h>
void main()
{
while(TRUE)
{
//Example blinking LED program
output_low(LED);
delay_ms(DELAY);
output_high(LED);
delay_ms(DELAY);
i2c_start();
i2c_write(0x31);
i2c_write(0x00);
i2c_write(0b00000111);
i2c_stop();
//TODO: User Code
}
}
|
Code: |
#include <16F1459.h>
#device ADC=10
#use delay(internal=16MHz)
#use i2c(Master,Fast,sda=PIN_B4,scl=PIN_B6)
#define LED PIN_B7
#define DELAY 1000
|
The observed behavior with my DMM and logic analyzer is that both pins B4 and B6 Remain high at 5V while in the loop and LED on R7 is blinking at 1Hz.
Here are my questions:
Do I need to declare TRIS, POR, LAT, other with the built in function #use i2c?
Can I use binary in an i2c_write command? hex only?
Why doesn't the flipping wizard tool actually work?
Thanks in advance
_________________ Tyson |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9243 Location: Greensville,Ontario
|
|
Posted: Tue Dec 10, 2024 5:45 pm |
|
|
1st, 10k pullups are too big, use 4K7 for 5 volts, 3k3 for 3 volts VDD.....
2nd, put the I2Ctest.c code IN your program. It's just 'silly and confusing' for it to be 'included'..heck 4-10 lines of code. having it as a 'header' also makes it difficult to 'see' what's going on.... well for me, but them I'm a dinosaur....
3rd, I don't use the 'wizard'. it was creted by someone else, so it does what HE wants NOT what YOU require it to do. HIS defaults will never be what YOU need. I also don't use 'debuggers', prefer to test in the Real World. Oh yeah... have you compiled using 'debug' or 'release' ? THAT will make a big difference...OK, I'm using MPLAB v8.92, cause I'm old, and well IT works for me...
4th DVM will never see I2C data, too darn fast.Have no idea if your 'logic analyzer' will see them. Again , as a dinosaur, I use a 20MHz analog scope so I can SEE what's going on.
5th, yes you can use binary in I2C writes, even base10
I'm sure others will respond... hope my comments help... |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19538
|
|
Posted: Wed Dec 11, 2024 3:19 am |
|
|
By default, the compiler will always clock things as fast as possible. So
your I2C, will almost certainly be set to run at 400KHz. Now a lot depends on
what gating options your logic analyser supports, but you need to set it
up to trigger on a falling edge on the SDA pin, and then sample at perhaps
1Msamp/sec for the next 30uSec. Otherwise you just will miss the data.
As Jay says, a scope set to trigger the same way, and running at perhaps
5uSec/div, is the way to see this (set trigger to norm, not auto).
What is connected to the lines?. This varies massively how much pull-up
is needed.
And, no you don't need to set TRIS etc., the compiler will be controlling
these for you.
As a comment, if you have an I2C device attached to the lines, are you
sure 0x31, is it's address?. Remember a lot of devices list their '7 bit'
address. If this is the case the value sent to talk to it would be 0x62, not
0x31.
Also the sequence would not be correct for a normal I2C device.
That looks like you are trying to write something to the device. In which
case the address must end on 0, not 1. The bottom bit is the direction
flag, and a '1' is saying this is a read command, which can then only
clock replies in, not stuff out. |
|
|
TYDOM78
Joined: 10 Dec 2024 Posts: 5
|
|
Posted: Wed Dec 11, 2024 11:17 am |
|
|
Thanks for getting back with me, several comments were very helpful.
CCS tech support got back with me yesterday.
Added force_sw to #use i2c(Master,Fast,sda=PIN_B4,scl=PIN_B6) and I was up and running.
I'm very aware of how to use a logic analyzer and oscilloscope. I use Saleae logic 8 analyzer highly recommend to save time with debugging protocols and for development in general.
10k pullups are fine for my application, depends on the slew rate you are targeting, power consumption, etc
You are 100% correct on the write vs read issue with the LSB, had to correct this with a bit shift.
Back to the wizard, this compiler is not free, if you pay for even the base compiler the built in functions should work with the wizard.
Yep, I get that the compiler is supporting (depending on what you pay for) up to 200+ devices but this really should be vetted out when you pay for it.
Arduino's IDE is completely free and the included functions work. There's actually a lot to say for open source collaboration on drivers. _________________ Tyson |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9243 Location: Greensville,Ontario
|
|
Posted: Wed Dec 11, 2024 11:33 am |
|
|
So now you're 'bitbanging' the I2C instead of the hardware ! Pic will run slower and loss of interrupts...
You should really see why the MSSP isn't working as it should. |
|
|
TYDOM78
Joined: 10 Dec 2024 Posts: 5
|
|
Posted: Wed Dec 11, 2024 11:55 am |
|
|
Fair enough, I am seeing some stretching of the bits (during Timer 0 and 1 interrupt running on my full code) due to bit banging most likely.
I can see the stretching with my analyzer.
So far, no issues with stable I2C writes AS IS.
My estimated capacitance is less than 5 pF in layout for SDA, SCL routing on my board so I don't believe the lack of SDA, SCL activity without force_sw is related to impedance mismatch with driving IO.
I'll circle back when I have more time to dig into this. _________________ Tyson |
|
|
waffles
Joined: 21 Dec 2021 Posts: 10
|
|
Posted: Wed Dec 11, 2024 1:43 pm |
|
|
You might need to dig into the assembly listing and investigate what the compiler is potentially doing wrong with the setup/usage of the MSSP on that particular chip.
It's interesting that CCS didn't offer any solutions outside of enabling the software I2C - did they offer any possible explanations as to what's causing this issue at all? |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9243 Location: Greensville,Ontario
|
|
Posted: Wed Dec 11, 2024 1:43 pm |
|
|
Just seems a shame to not use the builtin reliable MSSP that has a lot of benefits to it.In the end ,whatever works for you is what matters. |
|
|
TYDOM78
Joined: 10 Dec 2024 Posts: 5
|
|
Posted: Wed Dec 11, 2024 1:57 pm |
|
|
waffles wrote: | You might need to dig into the assembly listing and investigate what the compiler is potentially doing wrong with the setup/usage of the MSSP on that particular chip.
It's interesting that CCS didn't offer any solutions outside of enabling the software I2C - did they offer any possible explanations as to what's causing this issue at all? |
The person that contacted me, requested the LST file and then responded with:
Quote: | Before you were using the internal PIC I2C unit. That unit has been known to hang up if the bus capacitance is not to it's liking.
For a master the software I2C implementation is good.
|
_________________ Tyson |
|
|
waffles
Joined: 21 Dec 2021 Posts: 10
|
|
Posted: Wed Dec 11, 2024 2:19 pm |
|
|
Hmm... with that suggestion I'd potentially try a harder pull-up, but if you're satisfied with the hardware/bus parameters then I'd look at doing a minimal roll-your-own MSSP/I2C setup + data transmission.
Often there's some good code available on the microchip forums - getting it up and running with CCS involves creating appropriate register variables/aliases, etc...
i.e. https://forum.microchip.com/s/topic/a5C3l000000MTKDEA4/t342785
Good luck, hope you manage to resolve this issue! |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9243 Location: Greensville,Ontario
|
|
Posted: Wed Dec 11, 2024 3:27 pm |
|
|
curious..
'estimated 5pf cap'.... how did you estimate that ? What peripheral is connected to it, distance ? Same PCB ? Copper thickness, trace width ? Nonconformal coating ? How was PCB cleaned? ( I use dishwasher )
What did you really measure ??
I've used PICs with MSSP / I2C for 2 decades and never had a problem even when using the infamous 'white boards' .
Always used 5K( 4K7) pullups for 5 volts PICs, 3K(3K3) for 3 volt ones. Easy to remember.
If you're going to bitbang, get a cheaper PIC, one without MSSP. |
|
|
TYDOM78
Joined: 10 Dec 2024 Posts: 5
|
|
Posted: Wed Dec 11, 2024 3:54 pm |
|
|
I use the Saturn PCB Toolkit V8.06, my pcb stackup, trace width, the old/new fashioned calculator way to estimate not measure capacitance.
The device (PIC and Slave device) input capacitance per pin should be <10pF to meet I2C standards as per NXP UM10204.
My 1oz copper trace lengths for SDA/SCL are less than 0.5" total each, trace width is 7mils, distance to plane below is 5mils. This gets me to less than 5pF.
There are only 2 devices in I2C chain.
NXP standard on I2C max capacitance is < 400pF for standard 100kHz, and 550pF for 400kHz+.
Happy to drop my external pull ups to 2.2k and retest but I really don't see ANY activity on the I2C bus, literally nothing is being triggered using my logic analyzer or oscope with current setup without using bit bang approach. _________________ Tyson |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9243 Location: Greensville,Ontario
|
|
Posted: Wed Dec 11, 2024 4:55 pm |
|
|
I don't have that PIC , but perhaps someone will cut/paste/compile/test your 1st post code ?
If possible, post the listing of your 1st post program as I don't see why it won't toggle the I/O lines.... |
|
|
|