Only one I2C bus responding

[pklink]

Hi Giovanni,

thanks for the quick reply. Yes all the debug options are set to TRUE.

Greetings,
Pascal

[Giovanni]

I see nothing of obviously wrong. Try the guide here: http://www.chibios.org/dokuwiki/doku.ph ... e_shooting

Also, what is the value of "status" and what does i2cGetErrors() returns if status is not RDY_OK?

Giovanni

[pklink]

Hi Giovanni,

I checked everything that was written in the guide but everything seems to be fine.
Status is -1 after executing i2cMasterTransmitTimeout . If I then read out the errors with i2cGetErrors(&I2CD3) the function returns 0.
I sent a message to johntramp since he said he had his I2C3 bus working. I hope he can send me the complete code he used, since there were some defines which were not declared within the uploaded file on github. If this gets the I2C3 bus working I'll post it here.

Greetings,
Pascal

[pklink]

Hi Giovanni,

Up to now, I have some news which I think can help nail down the problem.
First of all, johntramp had, like me, no luck getting the I2C3 bus working and finally gave it up because at least another one was working.
Secondly, I tried out another sample project (the ARMCM4-STM32F407-DISCOVERY-MEMS in the demos folder). The funny thing is, that in this project the I2C2 bus is working, but not the I2C1 bus, so its the opposite as in my project, which was based on the I2C project in the testhal/STM32F4XX directory. I compared the mcuconf.h, halconf.h and chconf.h of both projects but I did not recognize any difference between the documents which was relevant to the I2C drivers. The two projects can be download using the following link:

https://www.dropbox.com/sh/6yhxkok6xd2e7io/T87M6ghjmx

It would be such a great help if you could find the time and want to check this code out (I know that probably many people in this forum ask you to check their codes out so I absolutely understand if you don't have the time). If you're lacking a STM32F4 board it would be a pleasure to provide you with one.

Greetings,
Pascal Klink

[Giovanni]

Hi,

I doubt it is a software problem, the code is trivial. Could you try to slow down the I2C and see if it makes any difference?

Debugging this requires a logic analyzer and see what actually happens on the bus between master and slave. I have lots of F4 boards but how to test the code without your same setup?

Try to PM barthess or see if he is available in the IRC channel, he could have an idea about this.

Giovanni

[pklink]

Hi Giovanni,

what I forgot to mention is that there is absolutely no signal on one of the I2C busses depending on the chosen project (I checked this with an oscilloscope) , so it should be independent from the slaves connected to the bus. However, I'll try to slow down the bus and see what happens this evening.
Thanks for the tip I'll send barthess a message.

Greetings,
Pascal

[Giovanni]

I just noticed this:

Code: Select all

txbuf[0] = HMC_CTRL_1;
txbuf[1] = 0b01111000;
i2cAcquireBus(&I2CD3);
status = i2cMasterTransmitTimeout(&I2CD1, hmc5883l_write_addr, txbuf, 2, rxbuf, 0, tmo);
i2cReleaseBus(&I2CD3);

You acquire I2CD3 but do the transmit on I2CD1.

Giovanni

[pklink]

Hi Giovanni,

did you find this in the I2C project? Because I checked the files on the dropbox and did not find the passage. (I exclude the MEMS project because I'm only communicating with this slave in the I2C example).
However, I tested acquiring one bus and using another one to actually communicate and it works. I'm everything else but an expert but I think that the acquireBus functions are only for reserving the bus for a thread so that other threads cannot use it.

Greetings,
Pascal

[Giovanni]

Hi,

It was in your post, I saw it while re-reading all from beginning: viewtopic.php?f=16&t=1168#p12170

You are correct about acquire and release, those are only needed if you want to share the bus.

Giovanni

[pklink]

Hi Giovanni,

I think I found the problem now. I'm only writing "think" because I had not the time (and knowledge^^) to really test the error but I'm pretty sure that this has to be the error. The two projects I used are using diferrent boards.c files. The testhal I2C project is using a file located in "NONSTANDARD_STM32F4_BARTHESS1" under "boards". The other project uses the file of the standard "ST_STM32F4_DISCOVERY" directory in "boards". I risked a quick look in those files and saw that there was a lot of PIN Declarations etc in there so I 'm guessing that maybe the Pin Mappings are different in the files and consequently I'm not using the same physical pins in the two projects allthough I'm using the same Pin number in the projects code.

As soon as I have time I will go through this but I thought I'll share this if maybe someone else has the same problem and needs a hint.

Greetings,
Pascal