1/1/2024 0 Comments Nucleo f401re arduino libraryI2C 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. 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 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |