I2C

[kodsurf]

I want to write a function that will send data over i2c into arduino for a test.

How should I know which freequency to use ?

LPC_I2C0
LPC_I2C1
LPC_I2C2
LPC_I2C3

???

Can you please tell which side (X+, X-,Y+,Y-) correspond to which LPC_I2C* device ?

3. I also remember that LPC_I2C devices should be switched ??? depending on which side we indent to use.

Please explain it again here in issues. How to select which I2C side on OBC (X+,X-,Y+,Y-) should be used and how to switch it ?

[kodsurf]

Extremely simple arduino code to receive transmitted data

Extremely simple arduino to transmit

Works well between 2 arduino nano if connected as

For OBC I should also use 4.7k resistor ? ( without resistors nothing works)

[RobertK66]

Hi,
as this is not a specific 'issue'. (Which I would defined to have some possible 'sollution'. (Either a bug with a fix or a feature with 'implementation ready') I moved this here to another 'discussion'.

[RobertK66]

Now to your questions:

• Pls. refer to the schematics for localization of I2C buses and pins! Current software only uses one of the 3 available. As stated in line 28 of ClimbObc.c this is the “Onboard” bus connecting to some sensors available on the OBC. The other 2 buses connect to A/B and C/D side panels.
• You also can see in the schematics(!) that the resistors to Vcc are provided on the OBC (R105/106 & R110/111)
• Speed: It depends on availability of connected slaves. You have to use the slowest speed of your connected slaves. Starting with 100kHz is pretty safe here (because I think this is one of the ‘slower’ bus frequencies commonly used)
• Panel selection: I had a short discussion about this with @andreassinn (TU). He told me how it was used in pegasus and I would do the same for Climb now: The ‘Selector’ Pins are only for ‘emergency configuration’ if one of the side panels “block the bus” (e.g. by short circuit to ground). In this case OBC could ‘disable’ one side to get the other one back to work….) For normal operation we can leave all sides ‘ON’. (Precondition for this is that all Slave addresses across side panel A/B and C/D are unique! (This has to be discussed and confirmed in CLIMB System Engineering meetings and designs, but I think it can be done ….)
  (I tested one of the 2 external buses here with my OBC and the Selector Pin was already switched to ‘ON’. So I think the values in our init structure are already good to go for it…..)

[RobertK66]

I opened issue #24 to reflect the need for code changes here.

[kodsurf]

I see now internal resistors on the schematics

Just to confirm - connection is simply 2 wires into arduino ? (Or I also need to connect resistors to Arduino VCC ? ) ( For every I2C device added resistors has to be connected to this devices VCC ?)

"The ‘Selector’ Pins are only for ‘emergency configuration"
Please explain how to control this selector pin from C coding perspective.

In current "dev" branch

I2C is initialized at LPC_I2C1

Which is at

p[0]19 and p[0]20

Which is according to shematics

"ONBOARD I2C"

Back to my original question :

Onwhich side (X+, X-, Y+,Y-) of OBC LPC_I2C1 should be located ?

In doccumentation avaliable to me (sidepanel pinout designations for every side X+,Y+,X-,Y-)

Those I2C ports are denoted as I2C-SCL/SDA-A I2C-SCL/SDA- B I2C-SCL/SDA- C I2C-SCL/SDA- D

Now again the question : How do I corelate A/B/C/D with X+,X-,Y+,Y- (physical OBC) and with LPC_I2C1,LPC_I2C2,LPC_I2C3 (C code)

[RobertK66]

The first part of this one is really a very good question ;-). 'Officially' (according to Carsten!) there is no usage of Side A/B/C/D 'allowed' in any form ( 😄 ). The only definition of satellite sides is: X+/Y-/X-/Y+ (and Z+/Z-) !!! That said, you can find A LOT (or maybe all :-) ) of pegasus/climb documentations refering to A/B/C/D. ( I think this is because you can not easily name variables, lines or pins with 'x-', ... in all sort of used tools, but ok .... )
I used to write the full correlation everywhere where it matters (e.g. see my uart definitions in pinning_climbobc.h line 95 ... 109). Trying to never make an error with this, I also have it (hadwritten) on my schematics page 7/8 and Andi also put it on the printed component side of the OBC-PCB. Having all 3 of this sources in front of me now, I here repeat them (hopefully correct):

we	Carsten/ESA
SP-A	X+
SP-B	Y-
SP-C	X-
SP-D	Y+

See also your Execl sheet above confirms at least the line SP-A / X+!

Note to our future: Be aware of this assignment beeng randomly chosen and error prone! Especially with newly designed hardware there could be integration mismatch, if somebody didn't get this correctly specified! It really depends on which side of the PCB you define as beeing Z+/Z- (Component side /solder side ?) -> it can result in 'clockwise' and 'anti-clockwise' PCBs 😃 .....

For me the above table and the OBC EM2 PCB defines "WHAT IS".

[RobertK66]

Now we can answer the 2nd part of your question with the EM2 schematics:
You find the I2C-switches on page 6/8. there you see that

1. the enable Pins are 'High active' because they are used as Vcc input to the switch-IC. So if you put them to low, there should be no output to the according side panel....
2. I2C0 is connected/connetcable to SP-C & SP_D
3. I2C2 is connected/connetcable to SP-A & SP_B

[kodsurf]

According to my latest test with "STP" branch I report following :

1. Was able to send request from OBC to Arduino.

2. OBC request bytes are WRONG. Arduino sends back correct reply bytes. ( Bytes received by OBC from Arduino are correct)

3. Only Y-(B) side works with i2c. Despite that according to my information LPC_I2C2 port is the same for A and B. Only B side "works"

When Osci connected to A side - strange signal detected.

4. C/D (LPC_I2C0) does not work completely. ( No signal whatso ever is detected by osci)

Note :

This is the way I controlled i2c side selector switches. By default all switches are initialized with HIGH state. Which corresponds to ENABLED.

If switch at B side is switched to LOW - LPC_I2C2 on B side stops working completly ( which is what I expected, thus B switch seem to be working correctly ?)

P.S - No Idea what elso to experiment regarding that. Need an advice.

[RobertK66]

Ok 2 ideas come to my mind here:

1. Stick with the 'it works' config
   -- Make a nice OSZI picture of the Clk/Data Line and try to see/analyze:
   -- What bits does the OBC put on the Data Line (when clocking out the OBC->Arduino bytes)? are they correct like expected?
   -- depending on this picture you either have OBC not sending correct data, or Arduino not receiving correct data. -> if signal level seem to be correct then check C pointer usage in the according SW parts ... Which data is messured/received (random? always same?) when you try to send different bytes?
2. From Szenario 1. only change your Arduino connection from B to A connector and then analyze:
   -- What do the 'strange signals' look like exactly !?
   -- are the signals before the switch IC correct (compare A with B switch Ic pins) this should be ok because the B side is working with same signals from uP....

I got the A(X+) side working correct with my hardware here (connected OBC to another LPC1769 Dev Board beeing the I2C Slacve). I think i will be able to chek with my OBC on thursday. I also will have a short look in your code then.....

[kodsurf]

1. No - Transmited bytes by OBC are wrong (not as expected) . This was confirmed by oszi picture. Together with Andreas Stren we investivated into bit by bit using oszi.

IMPORTANT NOTE : ONLY BITS CORRESPONDING TO ADDRESS WAS CORRECT.
I2C message structure contains on address and message. Address was correct. Message was wrong. And this is logical - if transmitted address was wrong - arduino would not have been able to receive the message !

So I STRONGLY suspect it is a SOFTWARE error somewhere within I2C library that is used.

*Bytes replied back by Arduino are always correct. Obviously if I am able see received bytes on OBC debug - they are correct. The same confirmed by oszi

Another note : Bytes transmited by OBC are random. (but with repetative pattern)

I tried changing lenght of message, and bytes yes - no effect.

FREQUENCY of I2C had "some effect" on bytes. !!!

I tried different frequencies 10,20, 100,400 khz . Oszi confirms that frequency defined in software is correct frequency that is actually used

Sometimes when I changed frequency - transmitted message of "OBC_hello" was received as "OC_he**" with partially correct bytes.

[RobertK66]

Ok, this is now the "Check your Pointers" part ;-):

Your C-code uses a variable declared locally within the i2cArduino_SendReadRequest() method (line 134).
This variable and your content of it is setup on the C-Stack here! The visibility of this variable 'ends' with the “}” of this method. You pass the pointer to it correctly to the I2C job, but when the I2C Hw-layer finally tries to read your data from there, this variable was 'randomly overwritten' by any C-Stack usage occurring after job-setup.

Using such Pointers to variables (on stack) is a common mistake in ANSI-C because you have to be aware that the stack memory used here gets overwritten after the declaring method was finished. (not exactly then but later with consecutive Calls and Stack usages. That’s the reason it sometimes looks to have correct content ) Normally it is some 'random' content (changed with every compile/reset or other timing relevant events) .....

So basically you make a I2c job which has its send data pointer pointing to 'undefined' memory position! ("Check your Pointers" part ;-):)

resolve e.g. by moving the variable out of the method to make it 'module - global'. Variables declared somewhere 'out of methods' get their own memory reserved in RAM - independend of the Call Stack - at compile time and stay available as long as nobody else uses the variable or a pointer to it .....

[kodsurf]

Naaa guuut

Stack overflow ....

Thank you very much for pointing it out about pointers ...

With code commit

a6755fc

issue of wrong transmitted bytes are fixed.

[kodsurf]

Also please note :

according to EM schematics - there should be pull up resistors integrated within OBC for I2C lines.

However .... If I just connect SDA, SCL lines from OBC to arduino - nothing works. I had to place those 4.7k resistors on ARDUINO side in order to achieve results described above.

!!! In my understanding (based on what I googled) for the whole I2C line (all devices) there should only be one pair of pull up resistors.

So what is wrong here ? why connecting dirrectly SDA, SCL ( and GROUND ARDUINI - GROUND OBC) did not worked without pull up resistors on arduino side ?

[RobertK66]

Is your arduino working with the same Vcc as the OBC? Is the GPIOP Voltage level of the arduino 3V3?
Make a OSZI picture without and with the connected 4.7k resistors. Whats the difference?

[kodsurf]

yes 3.3V

without 4.7 resistors there is no signal at all

[kodsurf]

oszi was connected parralel to sda scl lines

[RobertK66]

ok

without 4.7 resistors there is no signal at all
this looks to me as if the R106 / R111 are missing in your OBC !?

Do you have the same issue on side C/D (i2C0) ?

[kodsurf]

C/D on i2c0 does not work at all

[kodsurf]

Only B works.

I will do picture of "strange signal" from A side hopefully today

[kodsurf]

Image above is the CORRECT signal on B side with LPC_I2C2

Blue line is SDA
Yellow line is SCL

arduino address is decimal 57.

Message is "OBC_hello"

---

With the same code setup I reconnect to A side.

And get a "strange signal"

Nothing on a SDA line. And some strange stuff at SCL

[kodsurf]

A/B work as intended now.

C/D I triple checked connectivity - Connection - good. Still no signal

All switches were high.

SendReadRequest() I changed to LPC_I2C0

Init Data of module I also changed to LPC_I2C0

[RobertK66]

Ok for C/D maybe the PIN functions aren't set correct yet!? I never tested C/D, I also used A/B. on my side ...

[RobertK66]

your branch has this in the pin config !? (I think there smbdy (we) changed this to be used as debug output pins - somewhen.....)

//	[PINIDX_I2C0_SDA] = { 0, 27, IOCON_MODE_INACT | IOCON_FUNC1},	// I2C C/D
//	[PINIDX_I2C0_SCL] = { 0, 28, IOCON_MODE_INACT | IOCON_FUNC1},
	[PINIDX_I2C0_SDA] = { 0, 27, IOCON_MODE_INACT | IOCON_FUNC0, IOCON_DIR_OUTPUT, IOCON_OD_DISABLED, IOCON_VAL_HIGH },	// Use as GPIO Output
	[PINIDX_I2C0_SCL] = { 0, 28, IOCON_MODE_INACT | IOCON_FUNC0, IOCON_DIR_OUTPUT, IOCON_OD_DISABLED, IOCON_VAL_HIGH },

Pls. be more attentive to your code ......

[kodsurf]

Note that it is also the same func0 on Dev and master branch

[RobertK66]

I never tested C/D, I also used A/B. on my side ...