Home/Support/Support Forum/I2C on Connect ME 9210 and ESP 7.4 (also 7.3)
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

I2C on Connect ME 9210 and ESP 7.4 (also 7.3)

0 votes
Hi,

does anyone else have problems with I2C driver for NS9210?

On ESP 7.3 we had huge issues, including totally wrong speeds (2MHz?!) and I2C working only when run with JTAG. We solved this by supplying 0xFF as speed mode, and overloading rom.bin with ESP version (one delivered with module didn't work).

This week we bought ESP 7.4 upgrade, with hope lot of those issues will be solved. Well, speeds finally do work properly. But I2C works only when application is run using JTAG, when booted from Flash I see no I2C activity at all on pins with oscilloscope.

Now, probably issue we had before had to do with 7.4 rom.bin being loaded in factory?

I checked CCR, RSR and PWR registers on JTAG/rom.bin startups, everything seems to be fine (same values). Now, what else can be wrong?!

This has nothing to do with specific module - tried with many.
asked Feb 24, 2009 in NET+OS by fzawadiak New to the Community (2 points)
recategorized Dec 18, 2013 by tuxembb

Please log in or register to answer this question.

6 Answers

0 votes
I found when running release mode code from ROM (including the 'linked' rom.bin) that one of the two I2C pins wasn't being set up correctly - SDA was being set as an input rather than as an I2C pin.
I wrote a little checking routine which I called from various places, and which rectified the problem. This only occurs in 'release' mode.

void checkI2Cport(char *place, int resolve)
{
unsigned long temp0;
unsigned long temp1;
unsigned long temp2;
unsigned long temp3;
char status[10] = "OK";


#define ME9210_CONTROL_0 ((unsigned long volatile *)(NA_GPIO_CONFIG_BASE_ADDRESS))
#define ME9210_CONTROL_1 ((unsigned long volatile *)(NA_GPIO_CONFIG_BASE_ADDRESS+4))
#define ME9210_CONTROL_2 ((unsigned long volatile *)(NA_GPIO_CONFIG_BASE_ADDRESS+8))
#define ME9210_CONTROL_3 ((unsigned long volatile *)(NA_GPIO_CONFIG_BASE_ADDRESS+0xc))

temp0 = *ME9210_CONTROL_0; // Config 2 register.
temp1 = *ME9210_CONTROL_1; // Config 3 register.
temp2 = *ME9210_CONTROL_2; // Config 2 register.
temp3 = *ME9210_CONTROL_3; // Config 3 register.
if ((temp2 & 0x0ff00) != 0x0800)
{
strcpy(status,"Fail");
}
printf("%s: %08X: Config registers 0: %08X, 1: %08X 2: %08X, 3: %08X - %s\n", place, ME9210_CONTROL_0, temp0, temp1, temp2, temp3, status);
if (resolve && ((temp2 & 0x0ff00) != 0x0800))
{
printf("Reconfiguring control 2\n");
temp2 = (temp2 & ~0x0ff00) | 0x0800;
*ME9210_CONTROL_2 = temp2;
}
}

I found this last December - haven't checked properly whether any of the subsequent patches fixed it, but according to my debug flags its not fixed.

I've also found that the I2C sometimes fails to restart properly - if running in debugger, or if the ROM code is rebooted. Not ascertained the reason yet - the 'slaves' are custom-coded processors rather than I2C peripherals, so could also be a problem there.


Message was edited by: steved
answered Feb 25, 2009 by steved1 Community Contributor (85 points)
0 votes
Thanks a lot, this did help :-)
answered Feb 25, 2009 by fzawadiak New to the Community (2 points)
0 votes
I am having the exact same problem.

I2C will only work when the JTAG is connected in NET+OS 7.4.2

Does anyone know if there is a fix?
answered Apr 28, 2009 by nicklong New to the Community (9 points)
0 votes
On a quick look the problem appears to be the same (although I've not investigated in detail since I updated to 7.4.2).
I call the routine I listed above, which sets up the SDA pin correctly if it isn't, and that's fixed the problem.
answered Apr 28, 2009 by steved1 Community Contributor (85 points)
0 votes
Hi Steve

Thanks for getting back to me

I tried to run your example but ESP says
"NA_GPIO_CONFIG_BASE_ADDRESS" is undefined

EDIT: I was being a dope just had to:
#include <io_ctrl_mod.h>

Now it works like a charm, thanks Steve you are a lifesaver!


Message was edited by: nicklong
answered Apr 28, 2009 by nicklong New to the Community (9 points)
0 votes
This is actually tied to the recovery portion of the boot loader. By default it sets up GPIO 9 and 13 on the Connect ME 9210 as GPIO inputs (see customizeIsImageDownloadForced() in customizeBootloader.c) to check if they're being shorted to ground. The problem is, it never switches them back to their previous modes.

My understanding is that Digi has just released a patch for this that's available through Package Manager as well.
answered Apr 28, 2009 by charliek Veteran of the Digi Community (408 points)
...