2022-12-06 08:58 AM
Hello,
I hope you are doing well today. I have been working on a project that makes use of the M24256-DRMN8TP/K IC EEPROM product that STMicroelectronics manufacters. The project we are working on uses a Dialog DA14531 BLE chip. Recently I have been attempting to program the EEPROM through Renesas SmartSnippets_Toolbox however am running into a bit of a snag. The problem may fall with the DA14531 chip or software itself however, I would like to ensure that all possible reasons for the errors are covered. I just want to make sure that the configuration and setup I have for the EEPROM are correct.
For the I2C configuration written in C. This is done in SmartSnippets Studio
#define I2C_EEPROM_DEV_SIZE 0x20000 // EEPROM size in bytes
#define I2C_EEPROM_PAGE_SIZE 256 // EEPROM page size in bytes
#define I2C_SLAVE_ADDRESS 0x50 // Set slave device address
#define I2C_SPEED_MODE I2C_SPEED_FAST // Speed mode: I2C_SPEED_STANDARD (100 kbits/s), I2C_SPEED_FAST (400 kbits/s)
#define I2C_ADDRESS_MODE I2C_ADDRESSING_7B // Addressing mode: {I2C_ADDRESSING_7B, I2C_ADDRESSING_10B}
#define I2C_ADDRESS_SIZE I2C_2BYTES_ADDR // Address width: {I2C_1BYTE_ADDR, I2C_2BYTES_ADDR, I2C_3BYTES_ADDR}
I have connected the board to both a saleae logic analyzer and a oscilloscope to analyze the behavior of the I2C lines as well as the WC pin for the EEPROM to ensure that all behavior is as expected. The logic analyzer revealed issues when I would attempt to erase the contents of the EEPROM. I would receive consistent 'nak' errors for a few addresses then receive an 'ack' that would acknowledge the command to write and update the contents.
I believe the problem may lie in the DA14531 interface with the EEPROM or the SmartSnippets Toolbox and contacted Renesas Support, but would also like to see if anyone had experienced something similar with the same BLE or with another micro controller or microprocessor.
I have ensured the the WC pin on the product is not set to HIGH as it is connected to Ground however the behavior of the results is similar to that of the WC pin being set to HIGH at specific moments of the write process.
Forgive me if I am misinterpreting the data/results or leaving out any information. I am more than willing to share what I can to help resolve this issue. I have shared some screenshots of the logic analyzer while probing during the write and read process, I have also shared a results of the data output written to the terminal while probing the I2C lines. In the log text file you will get a more detailed showing of the nak and ack results.
Solved! Go to Solution.
2022-12-08 09:22 AM
You're typed the part number wrong twice the top post if you are using an M24256.
The part is 256Kbit or 32KB, so 0x8000 in size, not 128KB 0x20000
The page size is 64 bytes
Might be advisable to review the data sheet of the part you're using, thoroughly. It does provide method/sequence info.
https://www.st.com/resource/en/datasheet/m24256-df.pdf
2022-12-08 05:28 AM
Hello,
In this case not, the device would be still in buzy state when you send the next write sequence and thus responding NoAck.
BR
Pierre
2022-12-08 08:28 AM
2022-12-08 09:22 AM
You're typed the part number wrong twice the top post if you are using an M24256.
The part is 256Kbit or 32KB, so 0x8000 in size, not 128KB 0x20000
The page size is 64 bytes
Might be advisable to review the data sheet of the part you're using, thoroughly. It does provide method/sequence info.
https://www.st.com/resource/en/datasheet/m24256-df.pdf
2022-12-08 09:46 AM
Thank you for pointing the error I made, I went ahead and fixed it. The configuration Renesas recommended and that I am using was wrong. I have changed it to your recommendations and have received positive responses. Thank you for your help.