TE0701 How to enable 3V3_FMC supply

[TimS]

I have built a PCB that connects to the TE0701 via the FMC connector. I have pulled the FMC_PRSNT signal down to ground, but the 3V3_FMC supply remains off.

By testing the pins on Q1 (the 3V3_FMC switch) I can see that 3V3IN is present, but EN_FMC is low (0v), indicating that the CPLD (U14) has not enabled 3V3_FMC.

Is there something else I need to do to enable 3V3_FMC? The 5v supply on our TE0701 is broken, but everything else works at 3.3v

Tim

[Antti Lukats]

Hi

no nothing is broken: FMC standard says that the board VADJ voltage should be written to EEPROM and host enables VADJ after setting it to proper value.

TE0701 support programmable VADJ, and to support this default state of VADJ is simply OFF. VADJ setting must be written over I2C to the TE0701 Carrier Controller CPLD together with VADJ enable bit.

Then programmed voltage will appear on VADJ power rail.

I check if the I2C information is in our documents described if not it will be added.


Antti

[Oleksandr Kiyenko]

Hi

To enable FMC and J6 power you can execute this command from linux console.
i2cset -y 3 0x22 0x80

Note: "3" in this command is I2C bus number which depends on your configuration. You can found your bus number by scanning I2C buses
i2cdetect -y -r N
Were N is bus number. Found bus with active "22" address and execute first command to enable power.

Best regards
Alex

[TimS]

Hi Alex, Antti,

Thanks for your replies.
I assume this will enable both the FMC_VADJ supply from U18 and the 3v3_FMC supply controlled by Q1.
I will try the I2C commands you suggest when I'm back in the office on Thursday.

Tim

[TimB]

Hi, we have tried these commands now without success.

When we probe for i2c devices we get empty output on each bus that is probed, with the exception of buses 1 and 2 which each show `UU' at addresses 57-5a and also at 6f.

Can you suggest what the problem might be?

[Oleksandr Kiyenko]

Hi,

In default configuration (example project), I2C controller 1 connected to EMIF and then via glue logic to CPLD.
Do you have this code in your project ?

Best regards
Alex

[TimB]

Hi Alex, it transpires we haven't got this in our latest image, so we'll include it and try it.

thanks,

Tim

[TimB]

Hi,

we have now included the right code in our fpga build and can see the i2c devices, however, we can only see one address for the magnetometer/accelerometer 0x1e, whereas on your I2C addresses page you state that there should be two addresses 0x1e for the magnetometer and 0x18 for the accelerometer.  All the other addresses described seem to have come up ok.

[Oleksandr Kiyenko]

Hi Tim,

To see accelerometer address 0x18 i2c bus should be multiplexed. Glue logic code pass GPIO signal from Zynq PS to CPLD which implement this switch. In linux it's visible as multiple i2c buses in system.
In my case I see accelerometer on i2c bus 3. Check all i2c buses in you system to see all i2c devices.

Best regards
Alex

[TimB]

Hi, we see 4 buses when scanning, here is the output from each one.  I think all the addresses listed as valid I2C addresses (on your website) are detected with the exception of the accelerometer.  Is activating the switch something that should ahppen automatically, or do we need to send a command?

/mnt/i2c # ./i2cdetect -y -r 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --                         
/mnt/i2c # ./i2cdetect -y -r 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU --
20: UU UU UU -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- 38 39 -- -- 3c -- 3e 3f
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- UU UU UU UU -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU
70: -- -- -- -- -- -- -- --                         
/mnt/i2c # ./i2cdetect -y -r 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU --
20: UU UU UU -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- 38 39 -- -- 3c -- 3e 3f
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- UU UU UU UU -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU
70: -- -- -- -- -- -- -- --                         
/mnt/i2c # ./i2cdetect -y -r 3
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 1e --
20: 20 21 22 -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- 38 39 -- -- 3c -- 3e 3f
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- 57 -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 6f
70: -- -- -- -- -- -- -- --

[Oleksandr Kiyenko]

Hi Tim,

On by board I see
zynq> i2cdetect -y -r 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- UU -- -- -- -- -- UU --
20: UU UU -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- UU UU UU UU -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU
70: -- -- -- -- -- -- -- --
zynq> i2cdetect -y -r 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU --
20: UU UU -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- UU UU UU UU -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU
70: -- -- -- -- -- -- -- --
zynq> i2cdetect -y -r 3
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
20: 20 21 -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Are you sure that EMIO LSB GPIO signal output is routed to R15 pin ?

Best regards
Alex

[TimB]

Sorry, maybe I'm missing something here.. are you saying that is correct output? You don't seem to have any active addresses at all, except 20 and 21 on bus 3?

[Oleksandr Kiyenko]

Hi Tim,
Addresses marked with "UU" is active and handled by some driver, addresses with numbers are active but don't have driver.
As in 3.9 kernel accelerometer and magnetometer have drivers, so places 0x18 and 0x1E marked by "UU". If you remove driver definition from device tree you will see "0x18" and "0x1E".

Best regards
Alex

[TimB]

Ok, thanks, so how are the accelerometer and magnetometer accessed? Are there separate /dev/ entries that relate to them? Is this documented anywhere?

[Oleksandr Kiyenko]

Hi Tim,
You can access accelerometer and magnetometer via sys filesystem.
in my case from
/sys/bus/i2c/devices/2-001e/iio:device1/
and
/sys/bus/i2c/devices/3-0018/iio:device0/
For example to show current X value you can use command line
echo Magnetometer X value
cat /sys/bus/i2c/devices/2-001e/iio\:device1/in_magn_x_raw
echo Accelerometer X value
cat /sys/bus/i2c/devices/3-0018/iio\:device0/in_accel_x_raw

Best regards
Alex

[TimB]

Hi, another question on this for you: we are currently testing the magnetometer and the readings we are getting from it don't appear to be very linear.  They reach a point where they will suddenly jump, which makes us suspect that we are only seeing the low bytes of the reading.  From the data sheet we can see there is a high and a low register, is it possible that the driver isn't returning the contents of both these registers?

[Oleksandr Kiyenko]

Hi Tim,

We use standard linux driver, we don't modify it in any way. I don't sure that this driver have big problems, but if you want to check you can use i2cget command to read device registers and compare it with driver output.
Unfortunately, I did't work much with MEMs, so can't help you in this case.

Best regards
Alex

[TimB]

We have disabled the linux driver and are now accessing it directly as an i2c device.  We are now able to get linear readings from the magnetometer, so it would seem that there is some issue with the driver.

Having disabled the driver for both the magnetometer and the accelerometer, I can now see the magnetometer address 1e on 2 separate i2c buses (1 and 2).  I suspect one address is for write and one is for read (although I can read data from either bus), I was having problems setting some device registers when using the driver and my suspicion is that this is because it was using the wrong address.

I am having similar issues with the accelerometer, in that the behaviour of the accelerometer seems quite dependent on whether it knows that you are reading data from it.  The status register bits indicate whether the device thinks data has been read or not as if it writes more output data over existing data that hasn't been read, the overrun bits get set.  This is what I see despite the fact that I am reading the output registers.  And so my suspicion is that I am reading them using the `write' address and hence the device doesn't register that a read has happened.  The accelerometer address only appears once on bus 3.

[TimB]

I have found I can change the gain configuration using either magnetometer address but not the data output rate (on either address), which I think was the same behaviour I saw when using the driver.

[MarekC]

Hi Alex,

TE0701 rev. 3

I have some troubles locating I2C 0x22 address to enable FMC power.
I tried i2cdetect command and got exactly the same results as in your post quoted below.
However, I don't see 0x22 active in the reported results.

Regards,
Marek

Hi Tim,

On by board I see
zynq> i2cdetect -y -r 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- UU -- -- -- -- -- UU --
20: UU UU -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- UU UU UU UU -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU
70: -- -- -- -- -- -- -- --
zynq> i2cdetect -y -r 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU --
20: UU UU -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- UU UU UU UU -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU
70: -- -- -- -- -- -- -- --
zynq> i2cdetect -y -r 3
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
20: 20 21 -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Are you sure that EMIO LSB GPIO signal output is routed to R15 pin ?

Best regards
Alex

[Oleksandr Kiyenko]

Hi Marek,

This register is on separate I2C bus on TE0701. This bus is not connected in base project as it TE0701 specific.
To use it you should route SCL and SDA pins of this bus to Zynq I2C controller.
1) Add to your UCF file
NET i2c_scl_pin    LOC = W20  | IOSTANDARD = LVCMOS25;
NET i2c_sda_pin    LOC = W21  | IOSTANDARD = LVCMOS25;
2) In zynq configuration select EMIO for free I2C controller
3) In top level connect I2C EMIO signals to pins defined in UCF
4) Add selected i2c conroller description to devicetree (should already be here)
5) Scan all I2C buses
You should found something like thise

Code Select Expand


zynq> i2cdetect -r -y 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- 22 -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- UU UU -- -- 3c -- -- UU
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --


Best regards
Alex