Hi,

Apologies for the length of the post... I've tried to include all the relevant information...


I'm having an issue with my project. I have several I2C devices on the bus as follows:

The bus is driven by the PIC16F1509 hardware MSSP interface, using the API library functions in XC8, and using 6.2k pull-up resistors.

On project board:
- DS1307 RTC

Near project board
- TC74A0 temp sensor (tied to heat sink, on 8inches of 4-core cable, to I2C bus connections via screw terminals)

Remotely on the end of a 1.5m network CAT5 cable, socketed both ends*.
- two 8-bit I/O expanders (one reading buttons, one driving an LCD)

*I tested the connections etc. by running a network signal along the system before putting the chips on - it happily maintained a 1Gbps network between my laptop and NAS with no packet loss - on that basis, I believe my soldering and connections etc. are fine. I then populated the board with the components.


Everything runs fine if the DS1307 chip is left off the board. It will run for hours, no problem, using PWM to fade RGB lights up and down, displaying things on the LCD such as the temp read by the TC74 and keypress information.

If I plug the DS1307 in, the system locks up, holding SDA low and SCL high. This can happen anywhere from a few minutes to a few seconds after power-up, and the only way to recover is power down and up again.

Sometimes the system will unlock and then resume, but this is rare, and can take anything from 5 minutes to 15 minutes for this to happen. I only discovered this by accident when I left it on and looked for information online and it suddenly resumed.

The DS1307 also sometimes also returns nonsense when data is read.

The lockup will happen if the DS1307 is plugged into the board, even if the code to read it is removed. I have tried replacing the DS1307 with another - the issue is identical, so I think the chip is ok.

The only thing I can think of is noise on the I2C lines that run to the DS1307, maybe picking up interference from the IRL520 that are providing the PWM for the LEDs (driven by the PIC). Based on this, I disabled the PWM on the chip, and it seems to be running ok... no "nonsense reads" and no locking after running for 10 minutes - I'm trying running for longer to see if that is the issue.


I don't possess an oscilloscope... is there any way I can diagnose and verify my suspicions without buying one?

If I need to buy one, are these any good? I'm keen to use the computer, because my eyesight isn't the best, and being able to see the display on my 32inch TV while I poke the board with the probes and a magnifying glass REALLY appeals to me, rather than squinting at a 5-inch display.
http://www.ebay.co.uk/itm/Hantek-60..._Measurement_Equipment_ET&hash=item1c3de69f18

If the problem is due to noise from the IRL520 chips, is there anything I can do short of re-designing the board so that the components are in different places, putting the DS1307 as far away from them as possible?


Many thanks for any help!

 

First two bits of good news (though short of a solution):

The I2C bus is fully static, meaning you can run it as slow as you wish... a bit per hour is OK. By running the bus slowly you can use anything to debug it, from a digital (or even analog) voltmeter, or just a pair of LEDs.

Next, getting the SDA line stuck low should be an easy to clear fault, assuming it is from a faulty NAK signal: just toggle the SCL line a few times, perhaps as many as 9.

I'm not a big fan of the DS1307 chip as there are way better solution out there now so I don't have any expierence to suggest why it is going bad on you. I would suggest you try to isolate it's own SDA line during the fault to be 100% sure this is the chip causing the fault and not some other weirdess. I mean some way to see the SDA low, then unconnect just the SDA of the RTC and watch SDA go high.

I can't see EBay here, will check your link later from home.

 

Unfortunately once the SDA line gets stuck low for more than a few seconds, the PIC locks up... and the bus will only go down to 15kHz with the hardware controller.

What's a better solution than the DS1307? I must admit I used it mainly because it was cheap, and sounded easy to interface with, particularly when all you need by way of external components is a crystal and a 3V battery, and it'll keep time for years when the system is off. The battery-backed memory also sounded handy for storing alarm data etc. although this project doesn't use it. If there's something better than that, then I'm all ears!

 

My "goto" RTC device is the PCF2129 from Phillips. In single quantity from DigiKey it is just $3.08 USD (or 2.18 GBP if I read it correctly). This chip is also I2C but just needs the battery; the crystal is inside. With the crystal tucked away it runs very accurately as the chip monitors it's temperature and adjusts the internal clock to remove temperature variations. The big drawback is it only comes in SMD. I prefer SMD but some people still live in the 1990's ;-)

That USB scope only runs up to 20MHz which just might be enough to see what the PIC is up to. My home scope isn't much better, a nice classic analog Tektronics god for 50MHz or so.

Try hitting the usual suspects, here they are noise and noise: run the I2C bus slower (it helped me once) make sure the power is solid and well bypassed everywhere. Always appeal to a higher power.

Personally, I *hate* problems like you are having as they are very hard to track down, and you never quite know if they are really and truly gone.

 

What ErnieM said and.. This will sound strange but..

Make absolutely sure that neither you nor your library routines do any read-modify-write (bsf, bcf, andwf TRIS,F etc) on the TRIS register associated with the I2C port while I2C is running. When receiving, the PIC I2C asserts ACK by changing the SDA from an input to an output(0) in hardware. If this action comes coincident with the program doing r-m-w on TRIS, it will permanently lock SDA low. No amount of clocking SCL will clear it either since its not a lost slave. You also can't clear it by fiddling with the PORT/TRIS inits. The only way around it (that I know of) is to disable the I2C and re-init the port. You won't find this in the databooks but the problem was once described to me over the phone and subsequent internal document by uCHIP some years ago. I recall seeing something advising against r-m-w on TRIS and SFRs that have bits driven by hardware lately but don't remember exactly where. Even though the 1787 uses LATx for its IO ports, TRIS has the same old r-m-w issues. The problem exists in the 18F parts I've worked with as well. I don't know if its fixed in the enhanced midrange but .. ROFL - sometimes I just crack myself up! *gets up - wipes tears*

Review your code to make sure that it doesn't re-init PWMs that share the port while the I2C is active. Step 7 of the procedure says to clear the TRIS bits associated with the output. If that's done by r-m-w (and I'd bet it is) during an ACK - boom!

If you can, avoid any other outputs (unless shadowed) to the port shared by I2C (or any other peripheral that changes direction - PSP etc.). My personal rule is to only do inputs on the port shared by I2C. Even though we have LATx, you still need to avoid r-m-w on TRIS.

It wouldn't hurt to run it by uCHIP on a support ticket.

Good luck!

 

I'm using XC8, and with the hardware I2C in use, it screams red error messages all over the place if you try to use the port pins for anything else. So yes, checked that, and all fine there. With it being hardware based I2C, all you do is setup the port pins during configuration, then leave them alone. You then use I2C_MasterRead and I2C_MasterWrite as required, and it handles everything with a buffer and hardware interrupts. If you want to hold your program until it's finished a read or write, you just keep checking the "status" until it changes to either COMPLETE or FAIL.

Presumably they anticipated issues with the TRIS on PORTB (which uses RB4 and RB6 for I2C) because all the PWM etc. is on PORTA and PORTC, meaning the only thing PORTB is used for in my system is I2C - the other pins are not used, so I have set them up as inputs, then leave them alone. They're tied to ground on the board.


I've left the thing running overnight... it's been going now for over 10 hours and not locked up. The PWM output is OFF... so this is an issue that only happens when the PWM is running. I'm now feeling a bit more confident at pointing to possibly interference on the lines.

ErnieM "I prefer SMD but some people still live in the 1990's "

I love SMD... I just can't see well enough to wire it up! I don't want to use PDIP particularly and stripboard, it's just that's all I can really cope with. If you have any magic way of letting a silly bugger with not particularly steady hands and not the greatest eyesight deal with soldering SMD stuff, I'll be the happiest guy around! How do you make the circuit board though? I've never seen SMD stripboard and I don't have anything for etching boards.

ErnieM "make sure the power is solid and well bypassed everywhere. Always appeal to a higher power."

Ok, making sure the power is solid... I'm using a good quality 12V 5A supply, and I have a 470uF 25V cap tied between 12V and Gnd. I then have a linear regulator to give me a 5V rail, and another 100uF 16V cap tied between 5V and Gnd. Presumably that makes for nice solid power?

I'm not sure what you mean by "well bypassed everywhere" though. How do I do that?

 

By "well bypassed everywhere" I mean a 0.1 uF directly across the power & return pins of each and every IC in the system, with leads as short as possible.

"Stripboard" gives me the shudders, thankfully I discovered it very late in life and have never used it. I do admit 0.1" spacing is about the limit of human interaction for hand wiring which is why I keep a good supply of adaptor boards to wiggle tight SMD IC pads out to wide pads I can work with. My eyesight isn't what it used to be so I either work under a microscope or oneof those headband magnifiers. The headband is actually far more comfortable to use. Later I'll post some stuff I use (I really need to do a full write up of these things).

I've read JohnInTx very lengthy posts on the Microchip boards documenting the I2C problem. Trust us when we say it is real and Microchip again left a latent defect in all the I2C modules I have yet to see them either admit (and publish trustworthy work arounds) or correct the hardware.

(Aside to John: my idea for a work around is a global flag for "I2C active" that is tested and used to block any other routines from whacking the TRIS register. Of course, this only works on the master side of things.)

 

Presumably they anticipated issues with the TRIS on PORTB (which uses RB4 and RB6 for I2C) because all the PWM etc. is on PORTA and PORTC, meaning the only thing PORTB is used for in my system is I2C - the other pins are not used, so I have set them up as inputs, then leave them alone. They're tied to ground on the board.

re: Presumably they anticipated: very dangerous assumption. See ErnieM's 3rd paragraph. As for the rest - I misread the pin table - grr. It looks like you're OK in that dept but keep it in mind.

(Aside to John: my idea for a work around is a global flag for "I2C active" that is tested and used to block any other routines from whacking the TRIS register. Of course, this only works on the master side of things.)

Good thought. Unfortunately, we operated in the slave mode on early I2C modules.. fun.

 

ErnieM "Later I'll post some stuff I use (I really need to do a full write up of these things)."

Yes please! I'd be interested to know how to reliably make boards. I hate stripboard too personally, but I don't currently have a realistic alternative.

I long for the day when we can 3D print the circuit boards. Just pop a "blank" in and lay down the "copper" tracks.