Hi ,
i am using da14531 its our custom hardware , we have i2c communication using LIS2DH accelerometer , some faults occured in hardware related to i2c communication while reading LIS2DH_GetWHO_AM_I on failure case device continuously resetting the device, but on the same faulty hardware if i do flash the program without i2c communication its working fine,
the case i am expecting is on failure i should not reset the device , it should work with the other functionalities. how to resolve this ?
Thanks ,
Sowmiya
Hi Sowmiya,Thank you for posting your question online.Please attach the debugger while your application is running on the custom board so we can see where exactly it crashes.If it constantly resets, it means that there is either a Heap Exhaustion issue and the device resets or the WatchDog expired and caused the reset.Please refer here on how to attach the Debugger via Ozone: Tutorial Dialog SDK 6.0.x Debugging — DA145XX Tutorial SDK Getting started (renesas.com)Please also refer on our Git example we have with the LIS2DH accelerometer: BLE_SDK6_examples/interfaces/SPI_or_I2C_DMA_accelerometer at main · dialog-semiconductor/BLE_SDK6_examples (github.com)Best Regards,OV_Renesas
Hi OV_Renesas ,
Thanks for the quick response and the same code working fine with other devices. i am debugging the code its printing continuously the line print only and resets and again the printing the same ,
the case here is i know that the device has some i2c related issue in it but the application should not reset the device , in the faulty device without i2c portion its working fine advertisement. but once initialized the i2c its resetting continuously and debugged the each line to find where it restarts , the below function its resets
LIS2DH_GetWHO_AM_I in this function i have attached the function.
uint8_t accel_lis2dh_on_filetag(LIS2DH_Mode_t mode) { //char accel_sens[10]; // char movement_thres[10]; // uint8_t temp_accel_sens = 0, temp_movement_thres = 0; if(accel_config.state == CMD_ACCEL_STATE_OFF) { uint8_t chipID; int ret = LIS2DH_GetWHO_AM_I(&chipID); arch_printf("-------------->>> who am i %d\n",ret); // return MEMS_ERROR; if(accel_config.mode == LIS2DH_POWER_DOWN){ // arch_printf("1.LIS2DH_NORMAL \r\n"); accel_config.mode = LIS2DH_NORMAL;} else{ // arch_printf("1.ELSE MODE \r\n"); accel_config.mode = mode;} move_int_enable(accel_config.cb); //ENABLE INTERUPT if( !LIS2DH_WriteReg(LIS2DH_CTRL_REG1, 0x5f) ) //Turn on the sensor with ODR = 100Hz normal mode. return MEMS_ERROR; if( !LIS2DH_WriteReg(LIS2DH_CTRL_REG2, 0x00) ) // High-pass filter (HPF) disabled return MEMS_ERROR; if( !LIS2DH_WriteReg(LIS2DH_CTRL_REG4, instance_data.accel_sensiivity)) //0x30 , 0x10 //accel sensitivity // Full Scale = +/-2G (2G=0x00, 4G=0x10, 8G=0x20, 16G=0x30) return MEMS_ERROR; if( !LIS2DH_WriteReg(LIS2DH_CTRL_REG5, 0x00)) // Default value. Interrupt signals on INT1 pin is not latched. Users don’t need to read the INT1_SRC register to clear the interrupt signal. return MEMS_ERROR; //MOVEMENT file tag if(!LIS2DH_WriteReg(LIS2DH_CTRL_REG6, 0x20)) //enable interput on second pin return MEMS_ERROR; if(!LIS2DH_WriteReg(LIS2DH_INT2_THS, instance_data.move_thrshold)) //0x16 --> (working one) //0x02 // convert (08h to decimal)->64Threshold (THS) = 8LSBs * 15.625mg/LSB = 125mg.Free fall return MEMS_ERROR; if(!LIS2DH_WriteReg(LIS2DH_INT2_DURATION, 0x00)) return MEMS_ERROR; if(!LIS2DH_WriteReg(LIS2DH_INT2_CFG, 0x15)) // Enable XLIE, YLIE and ZLIE interrupt generation, OR logic. It means that the interrupt will be generated when X and Y and Z axis acceleration is within the ±THS threshold. return MEMS_ERROR; return MEMS_SUCCESS; } // arch_printf("MEMS_SUCCESS ON FILE TAG / tamp acel\r\n"); return MEMS_SUCCESS; }
Thanks,
Hi Sowmiya,Thank you for the reply.Are you sure you have configured correctly the I2C GPIOs?The I2C APIs we are providing, on the i2c.c driver and on the Git Repo example, have return error codes. Could you please debug and check the Return error codes so we could understand what is going on?I would also suggest you raise the Heap memory on da1458x_config_advanced.h file.By attaching a debugger on your custom board we will be sure on which line exactly the crash occurs.Best Regards,OV_Renesas