Skip to main content

i2c strange error

6 months ago

i2c strange error

Posted byThanhtu1310 points 9 replies
0 upvotes

Hi, i'm facing a very strange error with i2c devices. I use eeprom AT24C02 and realtime counter DS3231. Since they have the same i2c configuration(adress mode, word addres size,), i don't have to develope library for ds3231. i'm trying to read 7 bytes from AT24C02 and DS3231. in the i2c eeprom example(non BLE) i can read successfully. But in the ble_sleepmode example, in the callback function user_app_init(), i put some line of code to read 7 bytes from AT24C02 and DS3231. I can read 7 bytes from AT24C02(address 0x50).When i change the address to DS3231 address(0x68) --> debug --> Run, the ide jump to file nmi_handler.c and stuck in line 63. i have some captures in the PDF file.

62 if ((GetWord16(SYS_STAT_REG) & DBG_IS_UP) == DBG_IS_UP)
63 __asm("BKPT #0\n");
64 else
{

i have spent 2 days but i cannot find out the reason. Please help me!

i look foward to hearing from you soon.

Thanks!

Attachment 大小
result file 1.31 MB

5 months ago

PM_Dialog

Hi Thanhtu131,

I would recommend first checking theTutorial 8: Debugging methodsin order to start debugging your application code. Could you please find what is the point of the code that triggers the NMI?

So, if I understood correctly, it’s working on non-BLE projects but it doesn’t on BLE projects.

Are you using any of the available sleep modes?

Thanks, PM_Dialog

5 months ago

Thanhtu131 0 points

Hi, you have understood wrong. i can read the eeprom normally in both BLE and non-BLE example. But i can only read time from ds3231 in non-BLE example. In BLE sleep mode example, if i change the address from 0x50(eeprom) to 0x68(ds3231), something trigger the NMI. the default sleep mode is deepsleep mode. Things get more mysterious : i made an adpter board with the RST button connected to the RST pin on DA14580 basic kit, if i press that RST button, i can run the code and read the data from ds3231 and i have to do that every time i debug the program.

accepted answer!

5 months ago

PM_Dialog

Hi Thanhtu131,

>>>if i change the address from 0x50(eeprom) to 0x68(ds3231), something trigger the NMI.

You will have to start debugging your project. That’s why my previous answer was to follow the suggested tutorial.

Please run it in debug mode, add a breakpoint into the read function and step into the code so that you can find what is getting wrong.

Thanks, PM_Dialog

5 months ago

Thanhtu131 0 points

Hi, i have followed the suggested tutorial. and the hardfault occurred in the line which is the i2c_eepeom library driver of DA14580. Beside, when the hardfault occured, not thing has been log. if the line of code i found triggers the NMI, something must be log in the sereial monitor. I cannot fine the place to put the break point. Please check the attache PDF file.

Attachment 大小
i2c bug.pdf 374.77 KB

5 months ago

PM_Dialog

Hi Thanhtu131,

Can you please indicate which is the SDK function that triggers the NMI?

Thanks, PM_Dialog

5 months ago

Thanhtu131 0 points

As you can see in the i2c bug pdf file, the SDK function which triggers the NMI is WAIT_UNTIL_NO_MASTER_ACTIVEITY() (this is a macro which check for the involve register). i wonder why if i press the reset button (i made an adapter board which have a button connected to the RST pin header in DA14580 kit), i can run and debug the program

accepted answer!

5 months ago

PM_Dialog

Hi Thanhtu131,

The WAIT_UNTIL_NO_MASTER_ACTIVITY() is called in a couple of I2C APIs and let the application wait until the Master has no activity anymore.

从所附文件中,我假设引起NMI的WAIT \u UNTIL \u NO \u MASTER \u ACTIVITY()由i2c \u WAIT \u UNTIL \u eeprom \u ready()调用。

The i2c_wait_until_eeprom_ready() function is polling until I2C is ready. First, this function sends a dummy value and it is waiting until the FIFO of the Tx is empty. I strongly suggest you probe your pins (SCL, SDA and RDY) and try to read an address. If you try that, I think that it would be more clear what the problem could be.

What you can omit since this can cause you issues is the i2c_wait_until_eeprom_ready(), since this is for sending an extra byte to the I2C device in order to check if your device is ready for interaction, but other than that the i2c_eeprom_read_byte() function you get you on the bus what the datasheet of the I2C device describes.

Thanks, PM_Dialog

5 months ago

Thanhtu131 0 points

Hi, thanks a lot for your support, I've figuared it out that the issue comes from the DS3231 PCB. After changing another ds3231 module, the operation works normally.

5 months ago

PM_Dialog

Hi Thanhtu131,

Glad that you figured it out!

Thanks, PM_Dialog