Lionel95

up!

Hi Chris,

As you asked me, I've tried to deploy my project on Microframework v4.1 and the problem is still the same.

To go forward with my projet, I'm going to try to use SPI instead of I2C (fortunatelly the 16 bits GPIO extender MCP23017 exists as an MPC23S17, the same but with SPI port!) but the problem is not really solved this way and I2C port is much more interresting to use than SPI for me.

Let me know what I can test to help you to find the problem.

Lionel

Hi Chris,

In fact it's more complicated, when I say the I2C is crashed it means :

-In Reading function, the N+ is polling correctly the device, the device is responding but the value returned by N+ is false (allways 0x0FF instead of the right value) :

 Reading Normal.BMP   22.93KB   9 downloads

 Reading Crashed.BMP   22.86KB   6 downloads

-In Writing function, the bit Stream from N+ is incomplete :

 Writing Normal.BMP   25.43KB   5 downloads

 Writing Crashed.BMP   21.2KB   5 downloads

To make a good test, my breadboard is powered by a stabilized 12v power supply and a 7805 makes the 5v power supply. My N+ is powered by the USB port (the GNDs are common). In this way I can switch on and off the breadboard and the N+ separately.

Resetting the breadboard doesn't resolve the problem, the device still runs normally.

The N+ is still running but the I2C makes strange stuffs as you can see.

I'm going to flash the firmware v4.1 as you ask me and I'll tell you the result.

Lionel

Hi Chris, Hi Noom,

I've tried the class from Noom's playground and unfortunately I'm reaching the same issue.

@Chris : When I say I2C crashes, the rest of my app is still running but pressing  reset button just reboot my app, the I2C is still crashed. The only way to make it works again is an electrical off/on.

To make a "stress-test" I've made this with Noom's class :

A timer is reading GPIOA at Address 0x20 each 2 ms and the routine is returning the value I apply to the inputs. Then I'm playing very fast with a wire on the bit0 of the input (via an optocoupler), I can see the value (with a debug.print) changing from 1 to 0 and 0 to 1 but in about 15 secs the value returned is allways 255.

In this case if I reset my N+, the value is still 255, if i redeploy the app, the value is still 255 but if electrically off then on my N+, it works again.

With Noom's class, I can see the signals SCL and SDA are still correct, I can see the response from the MCP is correct too by counting the bits and seeing them still changing according to the value I code with inputs... This is why I think the bug is a crash from onboard I2C layer.

It turns my brain upside down and make it overheat!!!

@Noom and Chris : Maybe I could send you my project to make you see what happens. I'm a little bit disapointed with this issue. I have to deploy a card running 24/24 and I can't let it crashes without even the possibility to have a watchdog resetting it in case of failure.

Thanks again for your precious help.

Lionel

Hi NooM,

Yes, according to the datasheet, the mcp can operate up to 5,5v power supply.

I'll try your class and let you know if it solves my issue. Thanks again.

Lionel