Tag Archives: I2C

Close Encounters of the SD Memory Kind…

By | | , , ,
1 Comment

Sooo generally annoyed with sensors I decide to take a different direction, SD Memory.  Fun things happen with SD Memory.  You rip one open and you’ll usually find a single little flash memory chip and some other chip in front of it.  I haven’t identified the “guts” yet but that’s not really important.  What’s important is that generally you talk to that little flash memory chip using SPI (usually unless you wanna pay for licensing fees to use the direct SDIO method it sounds like.  Crazy licensing costs = faster SD Memory.  Free method = slow access.  If you need every bit of speed you can get then you’ll likely need that expensive method.  If you can buffer up data internally and then write it out later then you’ll use the SPI method).  This is likely to be preferred to have a built in memory chip to buffer items up just like working with a document on your computer.  It then isn’t until you save the file that it then transfers it from the internal memory out to the SD memory for transportation to the PC.

There is not much to it other than that except for having some structures that issue a few reads and writes to find a spot on the chip and make a file name and fill the file full of stuff.  That portion is the “FAT” portion that makes you able to read it on a computer etc.  This slows things down considerably in an SPI Method.  Apparently people have experimented with reading/writing to the SD memory chip with no

After a few days of poking at it and moving a couple wires around I’ve now managed to get it to make a file… and I can see that file on a PC.  The problem is I can’t get it to put anything INSIDE the file.   It just keeps getting stuck on the portion where it’s expanding the size of the file…  further it’s been quite a pain that any SD memory sample code out there is written focused on the 3xx series PIC32 and from looking at the various forums my issues are pretty common.  Most people get the 3xx series working just fine.  Many people seem to get files with no contents on 6xx and 7xx series PIC32s.

The only published successful people I’ve found seem to be commercial product developers who don’t want to share any code samples clarifying how to handle the failures properly.  The only exception I’ve found was some code modified by the user bmorse on mypic32.com.    His code appears to be modified to work specifically at 60mhz and using SPI2 which worked for initial testing to ensure I had things wired properly.   I needed to put a pull up resistor on the CS and the DO of SD to SDI2 on PIC32 and everything started working properly.

I’m now trying to isolate the portion of the code that affects the timing to increase the system speed back up to 80 mhz and scale the SPI back down again.   To assist in this department I’ve procured a FT232 UART to USB Com port chip on a breakout board from SparkFun.   This board is commonly used to take the UART output of various text and data from the running PIC and interact with it in the terminal window instead of watching the raw data on the debug watch.  I’ve learned that the watch window often “messes up” a lot of SPI states by constantly inspecting the information.  The idea is that it interrupts the normal state (data waiting etc) flags due to having read it for the watch window  blocking the rest of the circuit from detecting it.

I’ve also obtained a DS3234 clock.  At time time I only have the one I2C DS1307 clock and I may wish to eliminate the I2C bus unless I come up with something else that needs it.  Even if I use I2C elsewhere it seems as if 5 volt I2C is more of a rarity meaning I can’t really use that bus for other things anyway.

At the sound of the beep the current time is….

By | | , , ,
Leave a comment

So this weekend I consulted with another person on the Microchip.com Forums page about their I2C routines they had mentioned. After reading through their routines I looked at mine and found pretty much nothing different logistically except that he was accessing the bits directly rather than through the Peripheral Library. I scratched my head and modified the open command to use direct bits for the options I was enabling and suddenly noticed I had data in one of the slots with no collisions while running in regular mode that was always empty previously.

I had set the system up with a series of breakpoints to test I2C at full speed in one location and then break at the beginning of another set of data requests after closing everything out and resetting it. I always failed the first request and then worked in the second ones ONLY while they were in Debug mode. The second requests were always empty like the first one when they were allowed to run full speed / non debug. With this piece of success I then duplicated the change into my main routine instead of the initial test one and suddenly I had a full array of time and date filled and running properly.

While getting ready to blog this I was thinking of a title to use. The first thing that came to mind was the “Time Lady” that you could get the current time by dialing one of those XXX-1212 numbers in the phone book. She would say something like “At the sound of the beep the current time is 3:00…..exactly” or something like that. Upon googling to find the phrase she used I found this article. At the tone the time lady will be gone

Unfortunately it sounds like technology has caught up with the Time Lady. She was always there ready to serve us. RIP Time Lady.

Next up figuring out why my time in the CORNER of the LCD (not the memory slot being fed to the PIC32 RTCC) is showing funny things. Apparently there is some sort of Binary/Decimal/Hex/Whatever craziness going on. I need to find all the references and place Decimal to Binary conversions and hooking up SPI sensors.

Progress on I2C

By | | , , , ,
Leave a comment

So I previously had tried to get things working using a PIC24 and had both the thermocouple and a battery backed real time clock interfaced and communicating as well as some other items over SPI and I2C. Over time I decided I needed to focus on the PIC32 due to the memory, speed, and ease of interfacing with an LCD. I thus ordered the development kits for the PIC32 and a series of other parts and started this blog about them since I had to start over.

I have so far had tremendous problems with the I2C on the PIC32 hardware. In addition I seemed to show slightly more success with the other sensors over the RTC chip in particular. The RTC was provided by SparkFun as a breakout board. It does not have the pull up resistors on the break out board so it can be chained on to something that already has them… or else you need to insert your own resistors and power between the holes on the breakout board and the microprocessor pins.

After digging through an old box full of parts scavenged off of computers and an old 32 Port Audio Mixer that was destroyed while I was moving due to falling off the lift gate as I was finishing moving out of an old house I lived in. I’ve managed to create an I2C bus using a ribbon cable with some connectors pressed into it close together. I was then able to use a female header socket with some long pins and plug the DS1307 breakout into it for SDA and SCL. On the second connector I inject power into the other side of a header (the resistors are too thin to make contact in the normal connector for some reason). I then connect the third connector to the PIC32 pins using Female to Male jumper wire. Due to the length of the pins on the female header connectors I am able to clip the probes for a Logic Analyzer to the system.

After trying and trying and changing resistor values etc I was getting nowhere. I measure 5 volts on the I2C pins and with other sensors I could get confirmation of the bus going from on to off occasionally. With the RTC chip I was stuck at on. I had no idea what was happening and finally after several days of banging my head I yanked the backup battery out of the RTC.

Sparkfun claims that they have pre-programmed the time on the RTC and they are thus ready to be used/read etc without requiring time to be placed on the chip to start the oscillator. They also comment somewhere in the pages about how it should last about 9 years on the lithium battery provided blah blah. Apparently this is not entirely accurate. I have stumbled across several people commenting on the system NOT being programmed on their boards. In my case it turns out that the RTC chip simply is “hung” possibly caused by a malfunction of the battery. Upon removing the battery I noticed that it had “exploded” in one of the corners like they typically do when they get old. There was some rusted/acid crusted bits and leakage on the surface of the battery AND on the circuit board. I plugged it in again and ran some testing to it and it appeared to be accepting programming from the PIC32. After going to Radio Shack looking for a new battery I cleaned up the board and installed the new battery. The programming seems to stick now and all is well having provided a new battery. The old battery is currently reporting .8V instead of the normal 3.3v and is generally rusted and fouled up.

Unfortunately this story does not have freedom from flaws. It turns out that while running the routines normally I get results of either 0x0000 or 0x00FF. When I force it to debug mode, however, things appear normal displaying hours/minutes/seconds/date/month/year/etc in the appropriate slots and upon returning form debug mode back to normal show in the spaces I forced it to display the text. Further when I try to program it into a demo program Microchip wrote it seems as if the year is actually the “date”, the date is the “day of the week”, the month is the correct month, the hours and minutes dont make any sense. I’m not sure what is going on there. Taking a wild guess I’m thinking the date/year thing being weird is coincidental and that in reality there is perhaps some sort of Hex vs BCD problem going on.

Since I have achieved some level of success at this point though I am going to do a commit to the SVN repository on my server at home to make sure I don’t lose this code. I can see, with the Logic Analyzer, that the SCL and SDA pins switch from 0 to 5v and 5v to 0v from time to time so I know the pull up is functioning. What is troublesome is that the SCL pin never appears to have a functioning clock signal. Immediately after applying a Start command it appears to register a bus collision. I cannot figure out why this is happening and it further baffles me that I could program AND read I2C data without a functional I2C bus.

I was reading on the Microchip forums about how they, apparently, recently changed the I2C Library on the PIC32 making it function different than the PIC24. This is causing significant problems for PIC32 users. It seems to have something to do with the Idle state not being checked on the PIC32 causing collisions or something like that. How exactly this applies to what I’m doing I’m not sure because while the symptoms are the same it does not seem to follow the same circumstances.

In addition this weekend I obtained some LCD screen protectors (typically used for GPS) and removed the original covering provided by Microchip and installed the new protector. It is a lot smoother and easier to read the screen. I should be able to record the video on the screen without it being distorted once I get the I2C (and some SPI) sorted out and working.