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 F401RE CLION 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 F401RE CLION 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)
