I'm getting the software going for a MCP7940, and the I2C interface is giving me fits. This is with software that worked fine for a couple of ST inertial sensors. Has anyone had success or failure with this part? I'm getting ever- deeper into this, but at the moment it appears that the data is getting written and read correctly, but I'm getting NACKs at the ends of transfers. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Experience with MCP7940?
Started by ●November 17, 2015
Reply by ●November 17, 20152015-11-17
On 17/11/15 22:40, Tim Wescott wrote:> I'm getting the software going for a MCP7940, and the I2C interface is > giving me fits. This is with software that worked fine for a couple of > ST inertial sensors. > > Has anyone had success or failure with this part? I'm getting ever- > deeper into this, but at the moment it appears that the data is getting > written and read correctly, but I'm getting NACKs at the ends of > transfers. >What sort of part is it? I don't think I have heard of the MCP7940. But having just sorted out problems with an I2C interface on a Cortex M4 device that worked most of the time for most of the devices, are you sure you have the I2C pins set up in open collector mode? Mine were in push-pull mode, and most transfers were fine as long as I didn't check for ACKs.
Reply by ●November 17, 20152015-11-17
On Tue, 17 Nov 2015 15:40:46 -0600, Tim Wescott wrote:> I'm getting the software going for a MCP7940, and the I2C interface is > giving me fits. This is with software that worked fine for a couple of > ST inertial sensors. > > Has anyone had success or failure with this part? I'm getting ever- > deeper into this, but at the moment it appears that the data is getting > written and read correctly, but I'm getting NACKs at the ends of > transfers.Never mind -- the previous software was a bit too specific to the previous chip, and was messing me up. Clocks are clocking, life is, if not wonderful, at least back on track. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●November 18, 20152015-11-18
On 17/11/15 23:24, Tim Wescott wrote:> On Tue, 17 Nov 2015 15:40:46 -0600, Tim Wescott wrote: > >> I'm getting the software going for a MCP7940, and the I2C interface is >> giving me fits. This is with software that worked fine for a couple of >> ST inertial sensors. >> >> Has anyone had success or failure with this part? I'm getting ever- >> deeper into this, but at the moment it appears that the data is getting >> written and read correctly, but I'm getting NACKs at the ends of >> transfers. > > Never mind -- the previous software was a bit too specific to the > previous chip, and was messing me up. > > Clocks are clocking, life is, if not wonderful, at least back on track. >As long as the blinking LED is blinking - that's the most important part of any embedded system!
Reply by ●November 18, 20152015-11-18
On Wed, 18 Nov 2015 08:34:18 +0100, David Brown wrote:> On 17/11/15 23:24, Tim Wescott wrote: >> On Tue, 17 Nov 2015 15:40:46 -0600, Tim Wescott wrote: >> >>> I'm getting the software going for a MCP7940, and the I2C interface is >>> giving me fits. This is with software that worked fine for a couple >>> of ST inertial sensors. >>> >>> Has anyone had success or failure with this part? I'm getting ever- >>> deeper into this, but at the moment it appears that the data is >>> getting written and read correctly, but I'm getting NACKs at the ends >>> of transfers. >> >> Never mind -- the previous software was a bit too specific to the >> previous chip, and was messing me up. >> >> Clocks are clocking, life is, if not wonderful, at least back on track. >> >> > As long as the blinking LED is blinking - that's the most important part > of any embedded system!Except that I'm on to the next step, which seems to kill just about everything. I should blink the LED from the assert function! -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●November 19, 20152015-11-19
On 19.11.15 00:35, Tim Wescott wrote:> On Wed, 18 Nov 2015 08:34:18 +0100, David Brown wrote: > >> On 17/11/15 23:24, Tim Wescott wrote: >>> On Tue, 17 Nov 2015 15:40:46 -0600, Tim Wescott wrote: >>> >>>> I'm getting the software going for a MCP7940, and the I2C interface is >>>> giving me fits. This is with software that worked fine for a couple >>>> of ST inertial sensors. >>>> >>>> Has anyone had success or failure with this part? I'm getting ever- >>>> deeper into this, but at the moment it appears that the data is >>>> getting written and read correctly, but I'm getting NACKs at the ends >>>> of transfers. >>> >>> Never mind -- the previous software was a bit too specific to the >>> previous chip, and was messing me up. >>> >>> Clocks are clocking, life is, if not wonderful, at least back on track. >>> >>> >> As long as the blinking LED is blinking - that's the most important part >> of any embedded system! > > Except that I'm on to the next step, which seems to kill just about > everything. I should blink the LED from the assert function!Tim, does your master honor the clock clamp? Your symptoms could be coming from an attempt to slow down the master by the slave. -- -TV
Reply by ●November 19, 20152015-11-19
On Thu, 19 Nov 2015 17:33:02 +0200, Tauno Voipio wrote:> On 19.11.15 00:35, Tim Wescott wrote: >> On Wed, 18 Nov 2015 08:34:18 +0100, David Brown wrote: >> >>> On 17/11/15 23:24, Tim Wescott wrote: >>>> On Tue, 17 Nov 2015 15:40:46 -0600, Tim Wescott wrote: >>>> >>>>> I'm getting the software going for a MCP7940, and the I2C interface >>>>> is giving me fits. This is with software that worked fine for a >>>>> couple of ST inertial sensors. >>>>> >>>>> Has anyone had success or failure with this part? I'm getting ever- >>>>> deeper into this, but at the moment it appears that the data is >>>>> getting written and read correctly, but I'm getting NACKs at the >>>>> ends of transfers. >>>> >>>> Never mind -- the previous software was a bit too specific to the >>>> previous chip, and was messing me up. >>>> >>>> Clocks are clocking, life is, if not wonderful, at least back on >>>> track. >>>> >>>> >>> As long as the blinking LED is blinking - that's the most important >>> part of any embedded system! >> >> Except that I'm on to the next step, which seems to kill just about >> everything. I should blink the LED from the assert function! > > > Tim, does your master honor the clock clamp? Your symptoms could be > coming from an attempt to slow down the master by the slave.Nah, it was far stupider than that -- I was or-ing a '1' into a bit position that wasn't appropriate for the clock chip. It's what you get when you do blind copying and call it "code reuse". -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●November 19, 20152015-11-19
On 19.11.15 19:08, Tim Wescott wrote:> On Thu, 19 Nov 2015 17:33:02 +0200, Tauno Voipio wrote: > >> On 19.11.15 00:35, Tim Wescott wrote: >>> On Wed, 18 Nov 2015 08:34:18 +0100, David Brown wrote: >>> >>>> On 17/11/15 23:24, Tim Wescott wrote: >>>>> On Tue, 17 Nov 2015 15:40:46 -0600, Tim Wescott wrote: >>>>> >>>>>> I'm getting the software going for a MCP7940, and the I2C interface >>>>>> is giving me fits. This is with software that worked fine for a >>>>>> couple of ST inertial sensors. >>>>>> >>>>>> Has anyone had success or failure with this part? I'm getting ever- >>>>>> deeper into this, but at the moment it appears that the data is >>>>>> getting written and read correctly, but I'm getting NACKs at the >>>>>> ends of transfers. >>>>> >>>>> Never mind -- the previous software was a bit too specific to the >>>>> previous chip, and was messing me up. >>>>> >>>>> Clocks are clocking, life is, if not wonderful, at least back on >>>>> track. >>>>> >>>>> >>>> As long as the blinking LED is blinking - that's the most important >>>> part of any embedded system! >>> >>> Except that I'm on to the next step, which seems to kill just about >>> everything. I should blink the LED from the assert function! >> >> >> Tim, does your master honor the clock clamp? Your symptoms could be >> coming from an attempt to slow down the master by the slave. > > Nah, it was far stupider than that -- I was or-ing a '1' into a bit > position that wasn't appropriate for the clock chip. It's what you get > when you do blind copying and call it "code reuse".Good - it's a feather for you, you did find it yourself. -- -TV
