boards/stm32f4discovery: Change sda pin

[MrKevinWeiss]

Contribution description

This commit changes the I2C0 SDA pin to 9 from 7.
This is because the CS43L22 is connected to scl6 and sda9.
This PR has been taken over from #8812 from @graznik.

It states:

The STM32F4DISCOVERY on-board I2C peripheral CS43L22 is connected
to PB6 (SCL) and PB9 (SDA). Both pins have external 4.7K pull-up
resistors and are ready for I2C communication by default. The
default RIOT configuration uses PB7 as SDA pin which makes first
I2C bus bring up unnecessarily complicated.

The CS43L22 has an address of 0x5A (since the A0 pin is pulled down to ground) or 90 in decimal.

I don't have hardware to test on (at least stuff that works).

Testing procedure

BOARD=stm32f4discovery make -C tests/periph_i2c/ flash term
...
i2c_acquire 0
i2c_read_reg 0 0x5A 1 0

If you get an acked response with a value between 0b11100000 and 0b11100011 (or 224 to 227 in decimal) which is the CHIP ID and REVISION.

Issues/PRs references

Taken over from #8812

[smlng]

ACK, looks good. Verified with datasheet.

[aabadie]

Just had a look at this one and tested it on a board.

From the datasheet, the changes are good. But the testing procedure doesn't work:

2018-11-22 16:13:02,773 - INFO # main(): This is RIOT! (Version: 2018.10-RC1-207-gc6a7c-pr/fix/i2cpinout/stmdisco)
2018-11-22 16:13:02,774 - INFO # Start: Test for the low-level I2C driver
> i2c_acquire 0
2018-11-22 16:13:03,969 - INFO #  i2c_acquire 0
2018-11-22 16:13:03,970 - INFO # Command: i2c_acquire(0)
2018-11-22 16:13:03,971 - INFO # Success: i2c_0 acquired
i2c_read_reg 0 0x5A 1 0
2018-11-22 16:13:09,560 - INFO #  i2c_read_reg 0 0x5A 1 0
2018-11-22 16:13:09,561 - INFO # Command: i2c_read_reg(0, 0x5a, 0x01, 0x00)
2018-11-22 16:13:09,563 - INFO # Error: EIO [5]

This is weird because it should work normally.

[MrKevinWeiss]

Hmm I will try to look into it more, maybe I missed something.

[graznik]

Hi,

Thank you for taking over the pull-request! I still have a board and will try to investigate the issues at the weekend.

Cheers

Michael

[smlng]

blocking, until further testing

[smlng]

any news here?

[MrKevinWeiss]

Maybe things clear up when the #10610 gets merged, it should fix a bunch of these types of problems.

[smlng]

#10610 is merged, so?

[MrKevinWeiss]

@aabadie I think just needs retest when you have time.

[MrKevinWeiss]

Well a few things I noticed. The correct address is 0b1001010x which is actually 0x4A or if the addr pin is high it would be 0x4B. I was looking at the actual pins on the scope and couldn't find why it doesn't want to ack the address.

I can confirm the pin change is there as I probed the actual CS43L22 but I can confirm communication (maybe some other initialization stuff needs to be done). Do we want to merge or not?

looks good, waiting for test confirmation

[leandrolanzieri]

By setting PORT_D 4 to 1 I got the CS43L22 to respond:

2020-06-24 17:29:11,316 - INFO # Connect to serial port /dev/ttyUSB0
Welcome to pyterm!
Type '/exit' to exit.
i2c_acquire 0
2020-06-24 17:29:18,804 - INFO # i2c_acquire 0
2020-06-24 17:29:18,805 - INFO # Command: i2c_acquire(0)
2020-06-24 17:29:18,805 - INFO # Success: i2c_0 acquired
> i2read_reg 0 0x4a 1re 0
2020-06-24 17:29:22,162 - INFO #  i2c_read_reg 0 0x4a 1 0
2020-06-24 17:29:22,163 - INFO # Command: i2c_read_reg(0, 0x4a, 0x01, 0x00)
2020-06-24 17:29:22,168 - INFO # Success: i2c_0 read 1 byte(s) from reg 0x01 : [0xe3]

Change looks good. ACK!