Lukasz Forynski
2010-11-12 04:06:32 UTC
Hi,
I don't agree that pins are configured properly.. - I think that pad
configuration is clearly wrong in at least two ways (read below)
With the latest baseline you can also use the 'padconf' helper interface
located in:
http://developer.symbian.org/oss/FCL/sf/adapt/beagleboard/file/450a8cf0c020/omap3530/assp/inc/omap3530_scm.h
(it's still on Beagle_BSP_dev branch - but I will try merge it to the
default. It will be exported to the:
epoc32/assp/omap3530_assp/ (just like other common assp headers).
This should help keep the settings for pin/pads more consistent as each of
the register configures two pins, which very often are used by different
peripherals and always in the drivers (also in the I2C below) - the part
that is not of interest is not preserved (i.e it should be safely kept as it
was - not cleared or set to other value- -as this affect other drivers).
Also - the code does not have to be duplicated again and again - for each
driver. With this probably all other drivers should be updated too-I
intended to do that before merging entire Beagle_BSP_dev back to default.
In below example registers are attempted to be changed using 16 bit access
which is the first reason for likely wrong behaviour.. Secondly - the
addressing is wrong as an attempt to achieve the above.
Example of using helper functions for below examples is as follows:
CONTROL_PADCONF_I2C2_SDA[15:0] *i2c2_sda* is selected in Mode1
CONTROL_PADCONF_I2C2_SDA[31:16] *i2c3_scl *is selected in Mode1
SCM::SetPadConfig(CONTROL_PADCONF_I2C2_SDA,
SCM::ELsw, // (lower part of the register)
SCM::EMode0 |
SCM::EInputEnable |
SCM::EPullTypeSelect |
SCM::EPullUdEnable);
SCM::SetPadConfig(CONTROL_PADCONF_I2C2_SDA,
SCM::EMsw, // (higher part of the register)
SCM::EMode0 |
SCM::EInputEnable |
SCM::EPullTypeSelect |
SCM::EPullUdEnable);
Addressing of following two registers:
const TUint KCONTROL_PADCONF_I2C2_SCL = *0x480021BE;*
const TUint KCONTROL_PADCONF_MCBSP1_FSR = *0x4800218E;*
*is clearly wrong *- and this for certain produces unexpected results.
if this was supposed to be:
CONTROL_PADCONF_I2C2_SDA[31:16] *0x480021C0* for *i2c3_scl *(mode0
for I2C3_SCL)
CONTROL_PADCONF_MCBSP1_CLKR[31:16] *0x4800 218C* for *mcbsp1_fsr *(and mode4
for GPIO)
Registers at addresses: 0x480021C0 (and not ...21BE) and 0x4800218C (and not
...218E) - should be changed using 32bit access.
And again - for I2C only the 'higher part' of this register should be
updated - and the remaining part should stay unchanged.
This could be achieved with the proposed API as follows:
SCM::SetPadConfig(CONTROL_PADCONF_MCBSP1_CLKR,
SCM::EMsw, // (higher part of the register)
SCM::EMode4 |
SCM::EInputEnable |
SCM::EPullTypeSelect |
SCM::EPullUdEnable);
I shall merge at least only this part of the Beagle_BSP_dev tomorrow, so
that you could use the header and functions as listed above.
Cheers,
Lukasz.
I don't agree that pins are configured properly.. - I think that pad
configuration is clearly wrong in at least two ways (read below)
With the latest baseline you can also use the 'padconf' helper interface
located in:
http://developer.symbian.org/oss/FCL/sf/adapt/beagleboard/file/450a8cf0c020/omap3530/assp/inc/omap3530_scm.h
(it's still on Beagle_BSP_dev branch - but I will try merge it to the
default. It will be exported to the:
epoc32/assp/omap3530_assp/ (just like other common assp headers).
This should help keep the settings for pin/pads more consistent as each of
the register configures two pins, which very often are used by different
peripherals and always in the drivers (also in the I2C below) - the part
that is not of interest is not preserved (i.e it should be safely kept as it
was - not cleared or set to other value- -as this affect other drivers).
Also - the code does not have to be duplicated again and again - for each
driver. With this probably all other drivers should be updated too-I
intended to do that before merging entire Beagle_BSP_dev back to default.
In below example registers are attempted to be changed using 16 bit access
which is the first reason for likely wrong behaviour.. Secondly - the
addressing is wrong as an attempt to achieve the above.
Example of using helper functions for below examples is as follows:
CONTROL_PADCONF_I2C2_SDA[15:0] *i2c2_sda* is selected in Mode1
CONTROL_PADCONF_I2C2_SDA[31:16] *i2c3_scl *is selected in Mode1
SCM::SetPadConfig(CONTROL_PADCONF_I2C2_SDA,
SCM::ELsw, // (lower part of the register)
SCM::EMode0 |
SCM::EInputEnable |
SCM::EPullTypeSelect |
SCM::EPullUdEnable);
SCM::SetPadConfig(CONTROL_PADCONF_I2C2_SDA,
SCM::EMsw, // (higher part of the register)
SCM::EMode0 |
SCM::EInputEnable |
SCM::EPullTypeSelect |
SCM::EPullUdEnable);
Addressing of following two registers:
const TUint KCONTROL_PADCONF_I2C2_SCL = *0x480021BE;*
const TUint KCONTROL_PADCONF_MCBSP1_FSR = *0x4800218E;*
*is clearly wrong *- and this for certain produces unexpected results.
if this was supposed to be:
CONTROL_PADCONF_I2C2_SDA[31:16] *0x480021C0* for *i2c3_scl *(mode0
for I2C3_SCL)
CONTROL_PADCONF_MCBSP1_CLKR[31:16] *0x4800 218C* for *mcbsp1_fsr *(and mode4
for GPIO)
Registers at addresses: 0x480021C0 (and not ...21BE) and 0x4800218C (and not
...218E) - should be changed using 32bit access.
And again - for I2C only the 'higher part' of this register should be
updated - and the remaining part should stay unchanged.
This could be achieved with the proposed API as follows:
SCM::SetPadConfig(CONTROL_PADCONF_MCBSP1_CLKR,
SCM::EMsw, // (higher part of the register)
SCM::EMode4 |
SCM::EInputEnable |
SCM::EPullTypeSelect |
SCM::EPullUdEnable);
I shall merge at least only this part of the Beagle_BSP_dev tomorrow, so
that you could use the header and functions as listed above.
Cheers,
Lukasz.
Send Wild-ducks mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
http://developer.symbian.org/mailman/listinfo/wild-ducks
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Wild-ducks digest..."
1. Re: I2C status on SF^3 (Navneet Singh)
---------- WiadomoÅÄ przekazana dalej ----------
Date: Fri, 24 Sep 2010 00:20:39 +0800
Subject: Re: [Wild-ducks] I2C status on SF^3
I Looked up into the OMAP3530 TRM below code looks fine for Muxing the pin
in I2C2 mode..
Thanks and regards
Navneet Singh
+8613910204245
_______________________________________________
Wild-ducks mailing list
http://developer.symbian.org/mailman/listinfo/wild-ducks
To subscribe or unsubscribe via the World Wide Web, visit
http://developer.symbian.org/mailman/listinfo/wild-ducks
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Wild-ducks digest..."
1. Re: I2C status on SF^3 (Navneet Singh)
---------- WiadomoÅÄ przekazana dalej ----------
Date: Fri, 24 Sep 2010 00:20:39 +0800
Subject: Re: [Wild-ducks] I2C status on SF^3
I Looked up into the OMAP3530 TRM below code looks fine for Muxing the pin
in I2C2 mode..
Here is some old code to configure the padconf registers to enable the
// Definitions
// Pad Config registers
const TUint KCONTROL_PADCONF_I2C2_SDA = 0x480021C0;
const TUint KCONTROL_PADCONF_I2C2_SCL = 0x480021BE;
const TUint KCONTROL_PADCONF_MCBSP1_FSR = 0x4800218E;
const TUint KINPUTENABLE = KBit8;
const TUint KPULLTYPESELECT = KBit4;
const TUint KPULLUDENABLE = KBit3;
const TUint KMUXMODE0 = 0x0;
const TUint KMUXMODE4 = 0x4;
// Configure padconf
// Change the u-boot defaults to enable the I2C pins on the expansion
header.
AsspRegister::Write16(
Omap3530HwBase::TVirtual<KCONTROL_PADCONF_I2C2_SDA>::Value, \
KINPUTENABLE | KPULLTYPESELECT |
KPULLUDENABLE | KMUXMODE0);
AsspRegister::Write16(
Omap3530HwBase::TVirtual<KCONTROL_PADCONF_I2C2_SCL>::Value, \
KINPUTENABLE | KPULLTYPESELECT |
KPULLUDENABLE | KMUXMODE0);
// Set Pin 22 to be GPIO for interrupt line
AsspRegister::Write16(
Omap3530HwBase::TVirtual<KCONTROL_PADCONF_MCBSP1_FSR>::Value, \
KINPUTENABLE | KPULLTYPESELECT |
KPULLUDENABLE | KMUXMODE4);
The code is from a very old baseline so you might need to make some slight
modifications, but hopefully it will just work. Our boards are Revision B so
they donât have the J3 connector.
-George
*Sent:* 23 September 2010 03:42
*To:* Norton, George
*Subject:* Re: [Wild-ducks] I2C status on SF^3
Hi,
Here is the connection between the beagle board and sensor h/w .
Beagle board Sensor board (I2C
interface)
pin #1 of J5 <----> 3V
pin#27, #28 of J3 <----> GND
pin#23 of J3 <----> SDA
pin#24 of J3 <----> SCL
pin#1 of J3 <----> VDD1.8V
I saw your suggestion of multiplexing the I2c pins ie configuring the
padconf register on beagle board on I2c mode. So here I have to configure
the SDA pin in I2c mode.Do you have the code snippet for configuring the pin
in I2c mode ?
You are performing a synchronous register read, it blocks because your
device isnât responding to the read request.
If the device address is really 1100000 for read then the address should
be 0x60. This would explain why nothing is responding to the read.
If that isnât the problem then I suspect your I2C device isnât wired up
rightâŠ
How is it connected to the expansion header? Do you have a datasheet for
the part?
You have the levels right on the I2C lines (you might need
a level shifter)
You are supplying the correct voltage to the Magnetometer.
You have correctly configured the padconf registers on the
beagleboard (each pin on the expansion has about 4 different modes, you need
to make sure the I2C pins are in I2C mode).
If you have an Oscilloscope or Logic analyser, stick it on the I2C pins
and check you can see the signals.
Regards,
George
*Sent:* 22 September 2010 13:03
*To:* Norton, George
*Subject:* Re: [Wild-ducks] I2C status on SF^3
Hi,
I am working on Magnetometer Sensor driver and communication interface
to OMAP 3530 (Beagle Board) is I2c.It is hanged after executing a Read
statement. One more Info H/W connection with Beagle Board is not tested
.There may be a chance that I2c connection is not properly done.
Here Is the Code snippet for I2c Initialization.
//I2c Configure and opening the Handle for XYZ
I2c::TConfigPb iI2cConfig;
iI2cConfig.iUnit = I2c::E1;
iI2cConfig.iRole = I2c::EMaster;
iI2cConfig.iMode = I2c::E7Bit;
iI2cConfig.iExclusiveClient = NULL;
iI2cConfig.iRate = I2c::E400K;
iI2cConfig.iOwnAddress = 0x01;
iI2cConfig.iDfcQueue = iDfcQ;
iI2cConfig.iDeviceAddress = 0x30; //device address is 01100000 for
read & 01100001 for write
iXYZI2cHandle = I2c::Open(iI2cConfig); // Value comes out to be 48
rd = I2cReg::ReadB(iXYZI2cHandle, 0x00);
I added some prints in I2c module: So providing you the function also
----------------------------------------------------------------------------------------------------------
EXPORT_C TInt TransferS(THandle aHandle, TTransferPb& aWcb)
{
__KTRACE_OPT(KI2C, __KTRACE_OPT(KI2C,
Kern::Printf("+I2C:TransferS")));
Kern::Printf("+I2C:TransferS");
CHECK_PRECONDITIONS(MASK_NOT_ISR, "I2c::TransferS");
aWcb.iNextTransfer = 0;
aWcb.iCompletionDfc = 0; // indicate that it is a sync transfer and
the FSM needs to Signal the semaphore
Kern::Printf("+I2C:TransferS aHandle %d", aHandle);
TDeviceControl& dcb = DeviceCb(aHandle);
aWcb.iDcb = &dcb;
aWcb.iResult = (TInt)&dcb.iSyncSem; // use the async tranfer result
member to store the semaphore // Todo: store ptr to dcb in aWcb
NKern::FSSetOwner(&dcb.iSyncSem, 0);
TUnitControl& unit = UnitCb(aHandle);
AddToQueue( unit, dcb, aWcb );
NKern::FSWait(&dcb.iSyncSem);// Hanged here for more information se
hyperterminal dump below.
Kern::Printf("-I2C:TransferS:%d", aWcb.iResult);
__KTRACE_OPT(KI2C, __KTRACE_OPT(KI2C,
Kern::Printf("-I2C:TransferS:%d", aWcb.iResult)));
return aWcb.iResult;
}
void AddToQueue( TUnitControl& aUnit, TDeviceControl& aDcb, TTransferPb&
aWcb )
{
TInt irq = __SPIN_LOCK_IRQSAVE(aUnit.iLock);
Kern::Printf("AddToQueue Entry");
if (aUnit.iTransferQ == 0)
{
Kern::Printf("aUnit.iTransferQ == 0 aUnit.iState
%d\n",aUnit.iState);
__NK_ASSERT_DEBUG(aUnit.iState == TUnitControl::EIdle);
aUnit.iTransferQ = &aWcb;
aUnit.iCurrentPhase = &aWcb;
aUnit.iTransferQTail = &aWcb;
Kern::Printf("SetDFQ aDcb.iDfcQueue %d \n",aDcb.iDfcQueue);
aUnit.iDfc.SetDfcQ(aDcb.iDfcQueue);
Kern::Printf("Enque \n");
aUnit.iDfc.Enque();
Kern::Printf("Enque over\n");
}
else
{
Kern::Printf("aUnit.iTransferQTail->iNextTransfer == 0");
__NK_ASSERT_DEBUG(aUnit.iTransferQTail->iNextTransfer == 0);
aUnit.iTransferQTail->iNextTransfer = &aWcb;
aUnit.iTransferQTail = &aWcb;
}
__SPIN_UNLOCK_IRQRESTORE(unit.iLock, irq);
Kern::Printf("AddToQueue Exit");
}
-----------------------------------------------------------------------------------------------------------
Hyperterminal dump : I added some prints in I2c module
+I2C:TransferS
+I2C:TransferS aHandle 48
I2C DeviceCb device = 48
I2C DeviceCb return unit.iDevice[i]=48
AddToQueue Entry
aUnit.iTransferQ == 0 aUnit.iState 0
SetDFQ aDcb.iDfcQueue -938805192
Enque
Enque over
AddToQueue Exit
If you need any other info then do let me know.
Thanks in advance !
--
Thanks and regards
Navneet Singh
+8613910204245
Hi,
The I2C driver is working on SF^3 as it is used to talk to the tps65950
power management chip.
The touchscreen (but not on SF^3)
An accelerometer (but not on SF^3)
/sf/adaptation/beagleboard/omap3530/omap3530_drivers/i2c/test/
Can you provide more details about the crash? A register dump and
callstack would be helpful..
-George
*Sent:* 22 September 2010 07:18
*To:* Navneet Singh
*Subject:* Re: [Wild-ducks] I2C status on SF^3
The i2c driver in the wild ducks project is part of the Beagleboard
baseport and not part of S^3 itself. It should work.
I believe that Accenture, who wrote the original baseport and the i2c
driver, used it successfully for at least one peripheral (was it a touch
screen - George?) but I don't think that we've used it within the Symbian
Foundation or the Wild Ducks project yet.
How about telling us what you're trying to do with it and where/how it
crashes - then maybe someone can help.
Mark
Hi,
I am working on driver development of one sensor which require I2c
transfer and its crashing in I2c module.Is SF^3 I2c module is in working ?
--
Thanks and regards
Navneet Singh
+8613910204245
_______________________________________________
Wild-ducks mailing list
http://developer.symbian.org/mailman/listinfo/wild-ducks
Symbian Foundation Limited is a Company Limited by Guarantee and not having Share Capital
We're registered in England and Wales - Companies House knows us by the number 6683783
Our address is 1 Boundary Row, Southwark, London SE1 8HP.
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete the
original. Any other use of the email by you is prohibited.
_______________________________________________
Wild-ducks mailing list
http://developer.symbian.org/mailman/listinfo/wild-ducks
--
Thanks and regards
Navneet Singh
+8613910204245
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete the
original. Any other use of the email by you is prohibited.
--
Thanks and regards
Navneet Singh
+8613910204245
--// Definitions
// Pad Config registers
const TUint KCONTROL_PADCONF_I2C2_SDA = 0x480021C0;
const TUint KCONTROL_PADCONF_I2C2_SCL = 0x480021BE;
const TUint KCONTROL_PADCONF_MCBSP1_FSR = 0x4800218E;
const TUint KINPUTENABLE = KBit8;
const TUint KPULLTYPESELECT = KBit4;
const TUint KPULLUDENABLE = KBit3;
const TUint KMUXMODE0 = 0x0;
const TUint KMUXMODE4 = 0x4;
// Configure padconf
// Change the u-boot defaults to enable the I2C pins on the expansion
header.
AsspRegister::Write16(
Omap3530HwBase::TVirtual<KCONTROL_PADCONF_I2C2_SDA>::Value, \
KINPUTENABLE | KPULLTYPESELECT |
KPULLUDENABLE | KMUXMODE0);
AsspRegister::Write16(
Omap3530HwBase::TVirtual<KCONTROL_PADCONF_I2C2_SCL>::Value, \
KINPUTENABLE | KPULLTYPESELECT |
KPULLUDENABLE | KMUXMODE0);
// Set Pin 22 to be GPIO for interrupt line
AsspRegister::Write16(
Omap3530HwBase::TVirtual<KCONTROL_PADCONF_MCBSP1_FSR>::Value, \
KINPUTENABLE | KPULLTYPESELECT |
KPULLUDENABLE | KMUXMODE4);
The code is from a very old baseline so you might need to make some slight
modifications, but hopefully it will just work. Our boards are Revision B so
they donât have the J3 connector.
-George
*Sent:* 23 September 2010 03:42
*To:* Norton, George
*Subject:* Re: [Wild-ducks] I2C status on SF^3
Hi,
Here is the connection between the beagle board and sensor h/w .
Beagle board Sensor board (I2C
interface)
pin #1 of J5 <----> 3V
pin#27, #28 of J3 <----> GND
pin#23 of J3 <----> SDA
pin#24 of J3 <----> SCL
pin#1 of J3 <----> VDD1.8V
I saw your suggestion of multiplexing the I2c pins ie configuring the
padconf register on beagle board on I2c mode. So here I have to configure
the SDA pin in I2c mode.Do you have the code snippet for configuring the pin
in I2c mode ?
You are performing a synchronous register read, it blocks because your
device isnât responding to the read request.
iI2cConfig.iDeviceAddress = 0x30; //device address is 01100000 for read
& 01100001 for writeIf the device address is really 1100000 for read then the address should
be 0x60. This would explain why nothing is responding to the read.
If that isnât the problem then I suspect your I2C device isnât wired up
rightâŠ
How is it connected to the expansion header? Do you have a datasheet for
the part?
You have the levels right on the I2C lines (you might need
a level shifter)
You are supplying the correct voltage to the Magnetometer.
You have correctly configured the padconf registers on the
beagleboard (each pin on the expansion has about 4 different modes, you need
to make sure the I2C pins are in I2C mode).
If you have an Oscilloscope or Logic analyser, stick it on the I2C pins
and check you can see the signals.
Regards,
George
*Sent:* 22 September 2010 13:03
*To:* Norton, George
*Subject:* Re: [Wild-ducks] I2C status on SF^3
Hi,
I am working on Magnetometer Sensor driver and communication interface
to OMAP 3530 (Beagle Board) is I2c.It is hanged after executing a Read
statement. One more Info H/W connection with Beagle Board is not tested
.There may be a chance that I2c connection is not properly done.
Here Is the Code snippet for I2c Initialization.
//I2c Configure and opening the Handle for XYZ
I2c::TConfigPb iI2cConfig;
iI2cConfig.iUnit = I2c::E1;
iI2cConfig.iRole = I2c::EMaster;
iI2cConfig.iMode = I2c::E7Bit;
iI2cConfig.iExclusiveClient = NULL;
iI2cConfig.iRate = I2c::E400K;
iI2cConfig.iOwnAddress = 0x01;
iI2cConfig.iDfcQueue = iDfcQ;
iI2cConfig.iDeviceAddress = 0x30; //device address is 01100000 for
read & 01100001 for write
iXYZI2cHandle = I2c::Open(iI2cConfig); // Value comes out to be 48
rd = I2cReg::ReadB(iXYZI2cHandle, 0x00);
I added some prints in I2c module: So providing you the function also
----------------------------------------------------------------------------------------------------------
EXPORT_C TInt TransferS(THandle aHandle, TTransferPb& aWcb)
{
__KTRACE_OPT(KI2C, __KTRACE_OPT(KI2C,
Kern::Printf("+I2C:TransferS")));
Kern::Printf("+I2C:TransferS");
CHECK_PRECONDITIONS(MASK_NOT_ISR, "I2c::TransferS");
aWcb.iNextTransfer = 0;
aWcb.iCompletionDfc = 0; // indicate that it is a sync transfer and
the FSM needs to Signal the semaphore
Kern::Printf("+I2C:TransferS aHandle %d", aHandle);
TDeviceControl& dcb = DeviceCb(aHandle);
aWcb.iDcb = &dcb;
aWcb.iResult = (TInt)&dcb.iSyncSem; // use the async tranfer result
member to store the semaphore // Todo: store ptr to dcb in aWcb
NKern::FSSetOwner(&dcb.iSyncSem, 0);
TUnitControl& unit = UnitCb(aHandle);
AddToQueue( unit, dcb, aWcb );
NKern::FSWait(&dcb.iSyncSem);// Hanged here for more information se
hyperterminal dump below.
Kern::Printf("-I2C:TransferS:%d", aWcb.iResult);
__KTRACE_OPT(KI2C, __KTRACE_OPT(KI2C,
Kern::Printf("-I2C:TransferS:%d", aWcb.iResult)));
return aWcb.iResult;
}
void AddToQueue( TUnitControl& aUnit, TDeviceControl& aDcb, TTransferPb&
aWcb )
{
TInt irq = __SPIN_LOCK_IRQSAVE(aUnit.iLock);
Kern::Printf("AddToQueue Entry");
if (aUnit.iTransferQ == 0)
{
Kern::Printf("aUnit.iTransferQ == 0 aUnit.iState
%d\n",aUnit.iState);
__NK_ASSERT_DEBUG(aUnit.iState == TUnitControl::EIdle);
aUnit.iTransferQ = &aWcb;
aUnit.iCurrentPhase = &aWcb;
aUnit.iTransferQTail = &aWcb;
Kern::Printf("SetDFQ aDcb.iDfcQueue %d \n",aDcb.iDfcQueue);
aUnit.iDfc.SetDfcQ(aDcb.iDfcQueue);
Kern::Printf("Enque \n");
aUnit.iDfc.Enque();
Kern::Printf("Enque over\n");
}
else
{
Kern::Printf("aUnit.iTransferQTail->iNextTransfer == 0");
__NK_ASSERT_DEBUG(aUnit.iTransferQTail->iNextTransfer == 0);
aUnit.iTransferQTail->iNextTransfer = &aWcb;
aUnit.iTransferQTail = &aWcb;
}
__SPIN_UNLOCK_IRQRESTORE(unit.iLock, irq);
Kern::Printf("AddToQueue Exit");
}
-----------------------------------------------------------------------------------------------------------
Hyperterminal dump : I added some prints in I2c module
+I2C:TransferS
+I2C:TransferS aHandle 48
I2C DeviceCb device = 48
I2C DeviceCb return unit.iDevice[i]=48
AddToQueue Entry
aUnit.iTransferQ == 0 aUnit.iState 0
SetDFQ aDcb.iDfcQueue -938805192
Enque
Enque over
AddToQueue Exit
If you need any other info then do let me know.
Thanks in advance !
--
Thanks and regards
Navneet Singh
+8613910204245
Hi,
The I2C driver is working on SF^3 as it is used to talk to the tps65950
power management chip.
The touchscreen (but not on SF^3)
An accelerometer (but not on SF^3)
/sf/adaptation/beagleboard/omap3530/omap3530_drivers/i2c/test/
Can you provide more details about the crash? A register dump and
callstack would be helpful..
-George
*Sent:* 22 September 2010 07:18
*To:* Navneet Singh
*Subject:* Re: [Wild-ducks] I2C status on SF^3
The i2c driver in the wild ducks project is part of the Beagleboard
baseport and not part of S^3 itself. It should work.
I believe that Accenture, who wrote the original baseport and the i2c
driver, used it successfully for at least one peripheral (was it a touch
screen - George?) but I don't think that we've used it within the Symbian
Foundation or the Wild Ducks project yet.
How about telling us what you're trying to do with it and where/how it
crashes - then maybe someone can help.
Mark
Hi,
I am working on driver development of one sensor which require I2c
transfer and its crashing in I2c module.Is SF^3 I2c module is in working ?
--
Thanks and regards
Navneet Singh
+8613910204245
_______________________________________________
Wild-ducks mailing list
http://developer.symbian.org/mailman/listinfo/wild-ducks
Symbian Foundation Limited is a Company Limited by Guarantee and not having Share Capital
We're registered in England and Wales - Companies House knows us by the number 6683783
Our address is 1 Boundary Row, Southwark, London SE1 8HP.
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete the
original. Any other use of the email by you is prohibited.
_______________________________________________
Wild-ducks mailing list
http://developer.symbian.org/mailman/listinfo/wild-ducks
--
Thanks and regards
Navneet Singh
+8613910204245
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete the
original. Any other use of the email by you is prohibited.
--
Thanks and regards
Navneet Singh
+8613910204245
Thanks and regards
Navneet Singh
+8613910204245
_______________________________________________
Wild-ducks mailing list
http://developer.symbian.org/mailman/listinfo/wild-ducks