new iic with ip catalogue doesnt work

[aminbahrami]

hi all
(at first:thanx mr flibble for your answers I take it here,maybe some one else help me)

i am working with S3 adsp 3400.

this board needs two iic.

but bsb wizard only create one i2c forit.

I created another iic using ip catalogue for my design seccessfuly.

i initialized two ICCs correctly and write to connected chips to them.

first iic(which is created by bsb) works correctly but second iic dont work(writing has no reaction)

iic which i created is iic version 2.03 and iic created by bsb is iic version 2_01_a

I leaved the result of each stage below in the code

this is my code for writing in two iics:







#include "xparameters.h"
#include "stdio.h"
#include "xbasic_types.h"
#include "xiic_l.h"
#include "xiic.h"
#include "xio.h"

#define FMC_CARD_IIC_BASE_ADDRESS XPAR_XPS_IIC_0_BASEADDR
#define iic_board_base_addr XPAR_IIC_EEPROM_BASEADDR //BSB created iic
#define IIC_BOARD_MUX_ADDR 0x72
#define IIC_FMC_MUX_ADDR 0x74
XIic IicInstance; /* The instance of the IIC device. */
//int Status;
int cnt,ByteCount;
Xuint8 WriteBuffer[2];
Xuint8 ReadBuffer[2];


//================================================== ==

int main (void) {

WriteBuffer[0]=0x04;

XStatus Status;
Xuint8 StatusReg;

/*
* Initialize the IIC Cores.
*/
Status = XIic_DynInit(iic_board_base_addr);
if(Status != XST_SUCCESS)
{
xil_printf("\r\n failure in initialization \r\n");
return XST_FAILURE;
}
xil_printf("\r\n initialization passed \r\n");
Status = XIic_DynInit(FMC_CARD_IIC_BASE_ADDRESS);
if(Status != XST_SUCCESS)
{
xil_printf("\r\n failure in initialization \r\n");
return XST_FAILURE;
}
xil_printf("\r\n initialization passed \r\n");



//=================================writing data===============



cnt=XIic_Send (iic_board_base_addr ,IIC_BOARD_MUX_ADDR, WriteBuffer,1,XIIC_STOP);
xil_printf("\r\n cnt:%d \r\n",cnt);

//========================cnt is one in previous stage====================


cnt=XIic_Send (FMC_CARD_IIC_BASE_ADDRESS ,IIC_FMC_MUX_ADDR, WriteBuffer,1,XIIC_STOP);



//=====code proceeds to above line only and remains in final XIic_send function===========================

xil_printf("\r\n cnt:%d \r\n",cnt);
return 0;

}

 

[treqer]

adres iic cores correct?

 

[mrflibble]

You said in the other thread you used a scope for debugging. What signals have you probed so far, and what did you see? Maybe some screenshots? Or otherwise do you have chipscope captures of the sda/sdc signals? That would help others help you quicker than having another round of guess work .

That plus a check and recheck of all the addresses might be a good idea, considering the fact that that is a popular mistake.

iic which i created is iic version 2.03 and iic created by bsb is iic version 2_01_a

Any particular reason for this adventurous mixing of versions? I.e, why not use the same versions until you are 100% sure this is no issue. I am sure "that it should be no issue", but that's not the same as "it is no issue". If only from a maintenance point of view it is a bad practice to mix versions like this. For all we know version 2.03 could be having some issues with this particular thing for whatever reason.

 

[aminbahrami]

thanx.
I checked all of things you said again and again and again and again and...
I am confused.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
all of addresses are correct.
I checked the signals with oscope.
I have clock on scl pin but I have not data on sda pin!!!!!!!!!!!!!!!!!
the Ip catalogue tab supports only version 2.03 .
how can I change the version of my iic?
best regards

 

[mrflibble]

I have clock on scl pin but I have not data on sda pin!!!!!!!!!!!!!!!!!

Now that's a very good starting point to start fixing things. XD

Is that sda pin always low or always high?

Do you have the sda from the fpga properly routed? What do the sda + scl IOBs look like in the "IOB properties" overview in ISE? Maybe for some stupid reason sda is set to INPUT instead of BIDIR. Which together with the external pullup resistor would then make it always HIGH.

 

[aminbahrami]

it is allways low
sda is defined as io(bidirection).

 

[mrflibble]

it is allways low
sda is defined as io(bidirection).

Well, then you have something on the bus that is inadvertently always pulling it low. I2C in the inactive state should have scl high, and sda high. So when sda is low during idle there's something wrong there.

So that is either your design inside the fpga that's doing that, or something else that's on the SDA line.

Simple way to check: ditch the I2C for the offending pins, and change the sda pin to INPUT. If you then probe sda externally and you find it is HIGH during idle as it should be ==> the problem is inside the fpga. If sda still remains LOW despite having rconfigured that pin to INPUT, then the problem is somewhere outside the fpga.

 

[aminbahrami]

Dear freind.
excuse me
I was in hurry when I answered you yesterday.I saw voltage versus 3.3v and sda pin was zero.
I saw the pin voltage exactly today. sda voltage is always high

 

[mrflibble]

If you are certain that you really really measured the correct scl and sda pins, and you are certain that you see a clock on scl and an idle high on sda, AND you are certain that you verified that both SCL and SDA are set to BIDIR .... then that's weird.

What you could do is ... you have two i2c modules. one is working, the other isn't. Swap the pin locations.

So the old scl pin of module A is now then new scl pin of module B, etc etc. See if you suddenly now swap the working/non-working around as well.

Other than that, for remote debugging help I'd suggest chipscope + screenshots. Not much more I can think of without more info, since this isn't all that much to go on.

 

[aminbahrami]

dear friend
I am so sorry.
thanx
where are u from?
I am from iran.
In my country There is no one(or I dont know any body)who works with microblaze proffesionally.
I started myself from 4 mounths ago from point zero.!!!
I am glad now.
I can work with edk easily now because of your and others helps.
I must do this project as my MS thesis.
my brain is full of confusion now.
I need holiday more than every thing.
thanx again and again and....
the best regards.
amin

 

[mrflibble]

Hi,

No problems at all as far as I am concerned. All I mean is that remote debugging is always tricky even in the best of cases. Screenshots from signals of the actual hardware always help getting a better understanding of what is going on.

And sometimes all that's needed is taking a vacation from it all yeah. Then when you come back to it, quite often the solution presents itself. Oh, and I'm from the Netherlands.

Good luck with the MS thesis!