dsPIC33 I2C Slave

[Tin Duc Vo]

I was wondering if anyone could point me to a resource for using dsPIC33 MCU's as I2C slaves. I configured it as a slave with the Microchip Code Configurator as well as the peripheral library, but neither of them has been able to give me an interrupt.

I have set I2C2 to be used on the default pins as opposed to the alternative pins, set them as digital inputs, enable the I2C2 module, set interrupt priorities, cleared the flag, enabled the I2C2 slave interrupt, and enabled global interrupts overall. The interrupt vector I am using is "_SI2C2Interrupt".

What I am doing is changing the duty cycle of the PWM module to 50% when the interrupt occurs, but it never occurs. I am using a BusPirate to send a write command (with the programmed address) to the dsPIC33 and I have confirmed that the signal is indeed there with an oscilloscope, but there is no response. I'm thinking there should be an interrupt for the START, STOP, and address match events, but nothing happens.

If someone could help, that would be lovely.

[Maxlor]

PEIE?

[JPortici]

you are THINKING that there should be an interrupt for those events. but there isn't. or there is. or there are more than one. all is possible unless you read the datasheet/reference manual for the device you are using and verify that you have configured the pic as you want to.

First of all, what dspic are you using?
Is the i2c interrupt flag bit set when there is an event?
Are the interrupt enabled?
Is the interrupt mode and priority configured correctly?
in what conditions is the interrupt generated?
Does DMA play any role?
All of the above can be answered by first studying the datasheet and the family reference manual, I2C section first.
 
and last but not least
Does the i2c interrupt work at all with your pic? have you checked the errata?

[LeonV]

PEIE?

GIE?

[Tin Duc Vo]

Maxlor: PEIE doesn't exist for this microcontroller.

LeonV:  I used __builtin_enable_interrupts(); but I also just tried INTCON2bits.GIE = 1; and that didn't do anything. I'm not sure if the I2C is on at all because when I do a I2C sniff using a bus pirate and no addresses come back. I'm guessing it just sends all possible addresses out and looks for ACKS. This works to detect an IMU I had laying around. Isn't the I2C slave module supposed to generate ACKs automatically?

To JPortici: I'm using the dsPIC33EP32MC204. The flag does not turn on when I send "start 0x84 stop", "start 0x85 stop", "start 0x42 stop", or "start 0x43 stop" even with polling the value.

In order to try to enable the interrupt, I used the built-in "__builtin_enable_interrupts();", set GIE, cleared SI2C2IF, and set SI2C2IE. I set the priority of the interrupt to 1 and disabled all other interrupts, but I don't know what you mean by interrupt mode.

How I am understanding it is that the slave and master modules are independent and the slave generates an interrupt on address match and data received. I have never gotten any interrupts from my I2C module at all. I looked for the errata for my particular revision of the chip (ID= 4008 -> A8) and didn't find anything on TWI or I2C. I have read the entirety of the I2C document, but I still haven't been able to get this to interrupt (let alone everything else).

[Howardlong]

I realise this might not help immediately, but I _strongly_ recommend against using MCC particularly for parts that it's recently started supporting (i.e., it's full of bugs), and for things like I2C, because the code it generates is trying to be a jack of all trades.

In my experience I have spent much more time debugging the code that MCC generates than I would have done had I coded it up myself. It can't even get the oscillator right on many devices.

You can approach your project as a hybrid, with simple stuff like GPIO done by MCC and add your own stuff.

Also be aware that Microchip have a history of breaking MCC backwards compatibility, so you may find yourself having to regenerate your entire project again when a new version comes out, and also risk losing any custom changes you've applied.

Personally though, I have lost patience with MCC so many times that I only use it for generating an initial set of code which I then copy and paste into my own projects.

Irrespective, I'd be happy to take a look at your project (preferably cut down into the smallest reproducible example) if you can place it into a zip file. I have some dsPIC33EP128MC202s here (smaller package version of your device) so I am sure I can build your project on those devices.

[JPortici]

I have never used MCC and tools of such nature for anything more than aiding me in positioning the peripheral pins and outputing the configuration, as i'm usually skeptical about the abstraction layer introduced (for pics anyway the high and low level code is almost always compatible between parts, you just have to change the configuration of the pins, which i do with defines. For arm, i still don't do much arm to bother)

Back to the subject:
http://ww1.microchip.com/downloads/en/DeviceDoc/70000195f.pdf
On the family reference manual for I2C, section 7.2.1

INTERRUPT ON START/REPEATED START AND STOP CONDITIONS
(SLAVE MODE)
The user software is notified through a slave interrupt if the SCIE bit (I2CxCONH<5>) is set for
a Start/Repeated Start condition or if the PCIE bit (I2CxCONH<6>) is set for a Stop condition.

Figure 7-3 is a nice timing diagram of all the signals in slave mode

And it goes on in detail for all the rest of section 7

But basically the two aforementioned bits have to be set in order for the pic to generate an interrupt in those conditions... but i would first check if the signals are received correctly by the module so for example by polling the P and S bits in the i2cstat register

There is also a nice code example called CE445 - Using I2C module as Slave device, located at the bottom of the product page

[Tin Duc Vo]

Howard Long: What kind of issues have you had with MCC? In the beginning, I thought it would handle most of the work with things like the TRIS and ANSEL registers, reducing headache, but I could see it being sketchy. It couldn't do the clock calculations properly having me confused about why the formula the MCC used was different than the formula in the datasheet. Thanks very much for the offer, but as of now I am not allowed to share any code with someone outside the project. But ... I am working on another personal project. Are there any other manufacturer tool I should be worrying about? I'm looking at getting one of the lower power STM32 microcontrollers.

JPortici: The SCIE and PCIE bits don't seem to exist on the MCU. I will try polling the P and bits. It might be possible that the MCU address matches, but does not ACK.

Thanks .

[Howardlong]

The trick is to get a unit test project working without interrupts first. Once that's surmounted, the additional complication of interrupts can be considered.

But foremost, I'd avoid MCC for I2C, in the short, medium and long term, it's an unnecessary complication, ironic considering MCC is meant to simplify things!

The aim of MCC is clear, to take the chore of boilerplate configuration code away and leave the programmer to fill in the business logic. It oversteps the mark when it tries to generate driver code in my opinion. Far from being an aid, you end up having to learn how to drive the driver, while still having to know how the peripheral works at the hardware level.

[Tin Duc Vo]

Thank you everyone. I ended up finding out that one of the pins were used by default for fault detection in the hsPWM.