It is used to read the data from the device.
Nucleo f446re i2c pins code#
It is critical that the READ and WRITE calls inside the I2CSlave code match the data length and the same length values are used by the I2C Master else there will be timeout / SCL locks.ĭuring the launch of the posted code, the title is printed but never the first R/W I2C transaction which may be due to buffering of the printf.I2C_Read is probably the most complicated part. Here are the results which appear to show the posted code works. Configured our CAS-1000 tool as the I2C Bus Master. After reading about this issue, invested some time to configure the same Nucleo STM32F401 board as the I2C slave with I2C ID of 0xa0 using the posted example. Summary: The 'secret' to making this mbed code work is to take care to use the proper packet length value as shown in the above example. Welcome questions from other developers if you would like for me to test this setup beyond the above code.
These tests appear to show the I2CSlave code is working with the tested STM32F401RET6 based Nucleo. I2C pull up resistors are 4k7 for SDA and SCL pins.
Can perform random R/W transactions (but with the fixed string lengths) with the I2CSlave board without lock 1 Mhz for SCL -> works to write to the mbed I2CSlave but read from the I2CSlave locks with SCL. Impressive !! Higher speed than 806khz for SCL are flaky as noted below. Printf("\r\n Read A: %s", counter++,buf) įor(int i = 0 i works to read / write with the mbed 500khz for SCL -> works to read / write with the mbed 806khz for SCL -> works to read / write with the mbed I2CSlave. Printf("\r\nRead from inside WRITE I2C routine. Printf("\r\nRead from I2C slave & sending local %02d byte string to I2C master %s",strlen(msg) + 1, msg) Printf("Hello from I2CSlaveTest program for mbed.\r\n") Unsigned char my_i2c_slave_address = 0xa0 Ĭhar msg = "Slave!" // 53 = S 6C = l 61 = a 76 = v 65 = e 21 = ! 00 = end of string marker => read of 7 bytes by I2C master **Question:** So is this a general MBED I2C problem or something specific to the MBED I2C Slave implementation with STM32 NUCLEO boards? Question: So is this a general MBED I2C problem or something specific to the MBED I2C Slave implementation with STM32 NUCLEO boards? I do have similar code running on a Teensy 3.2 using the Arduino (Wire) library and this blocking/long-ACK behavior is not present. As long as the receivers have some wiggle room (with proper I2C library buffering), the apps should not be throttling on a per write basis.
Nucleo f446re i2c pins serial#
The real master, however, will be processing input over serial at 31250 bps which must be pushed to other processors in real-time. This was done by simply throttling with wait_ms() calls (as suggested above). The only way I found around this was to throttle the master such that it would not write until the slowest slave could finish reading/processing the previous write (sort of like having a small 2 byte buffer). Looks like someone else is in a similar situation here: I tried the same code and see the same results using 3 different STM32 NUCLEO boards: I2C is how the multi-MCU system I'm building was supposed to communicate. Unfortunately, this is causing me to rethink the leap from a prototype using Arduino over to an MBED/STM32 environment (maybe more of a step then a leap, but you get the idea).
So please remove the call to printf, or add a suitable pause / wait on the master side to allow printf to happen before sending the next commandįolks, I'm having the exact same problem. I could check on a scope that the 10 bytes are well received, and SCL as well as SDA are back to normal (high) state. So if by removing call to printf, I have the test working fine: In order to keep real time answer, it's better to get rid of the printf (useful for quick debug, but not adapted to real time answer needed by an I2C slave). Nevertheless, there is an easy way to avoid the problem on the slave side.
Nucleo f446re i2c pins how to#
In this case, I reproduce a similar issue as you see and I will try to investigate how to recover from the error. I somehow reproduced the issue this morning and please find below my first findings:įirst I used another NUCLEO board as a master and used the test code belowĬhar buf = Slave.write(msg, strlen(msg) + 1) // Includes null char The following is the snippet of the test code:
The NUCLEO-F401RE i2c slave always holds down the SCL line forever in middle of the data transfer, which can be viewed clearly by a oscilloscope or a I2C protocol analyzer. I used the Total Phase Aardvark I2C host adapter sending bytes (8 bytes) to NUCLEO-F401RE board. I was using the mbed OS 5 i2c slave example () with the bit rate standard 100K bit/s. I am having a problem using NUCLEO-F401RE board for testing the i2c slave.
0 kommentar(er)
