Hi, Really thanks for all the help you've been. I'm sure I'll need more help on the way, but this seems to be working now. I played around with the code a lot in the past couple of days and then searched about this kind of weird behavior (Code getting stuck at a position that it was able to run through, with the only difference being that there is a little more code or little more variable declarations. ) I found out that it was due to the very heavy hierarchy of functions being present in the BMI270_API and a relatively small stack space (512 bytes) being allocated. Both of these combined, basically resulted in stack overflow, which then resulted in Fault_ISR being called. a reference link (TI's E2E forum): https://e2e.ti.com/support/microcontrollers/other/f/other-microcontrollers-forum/430818/launchpad-s-strange-faultisr I increased the stack space to 1024 bytes from 512 bytes, and the program runs fine. The conversion has some issues, but I was not interested in the conversion anyway. Again, lots of thanks for helping me through this. I've left the link for the reference above, just in case someone else has similar issues again in the future. Thanks and Regards, Punit Jain
... View more
I checked further, it happens that, whenever I assign anything related to "struct bmi2_sensor_data sensor_data", The code compiles, but results in runtime error and ends up in Fault_ISR while loop. even a part of the code which is simple as this: // Assign accel and gyro sensor.
sensor_data[ACCEL].type = BMI2_ACCEL;
sensor_data[GYRO].type = BMI2_GYRO; throws an error. The code is able to read the chip ID, however. but fails in the bmi270_init(). My guess is, this structure contains a uint8_t type variable and a union. As in C, union's size will be limited to the max of the sized of it's elements, it is not able to work properly. Should I convert all of the unions to struct types?
... View more
I tried implementing the whole startup sequence using bmi270_init(); I figured out that the error was, that I was not clearing the RX buffers after transmitting in legacy mode. But that is taken care of now. As of now, the bmi270_init runs fine (the return for that function is BMI_OK (0x00)). and the register at 0x21, has it's LSB as 1, which means that the initialization has been successful. But when I try to run this: bmi270_get_sensor_config(), it gets stuck in the first SPI read function. From bmi270_get_sensor_config(), it goes to bmi2_get_sensor_config(), and then to get_accel_config() and then to bmi2_get_regs(), where it terminates with an error to Fault dead loop. I tried debugging the error, and found out that the size of the data space allocated for the read function is not enough for the read to be done. Edit: I checked further, the size of the array is sufficient. The issue is something different, it seems. It is getting stuck when reading two bytes from Register 0x40, so, 0x40 and 0x41. I tried reading those two registers directly by using the bmi2_get_regs() function, and it is reading the registers properly. The values are @0x40: 0xa8; @0x41: 0x02;
... View more
I had tried modifying the bmi270.c file, commented out the functions whose definitions were clashing with the ones in bmi2.c. The compilation went fine, but then bmi270_init gave a result of 0xfd, which is -3. According to bmi2_defs.h, it corresponds to BMI2_E_DEV_NOT_FOUND. I checked further, it is due to chip_id mismatch. I am not initializing the intf_ptr present in the bmi2_dev structure? Are these related? I tried to understand your codes, the files you're using for bmi270.c and bmi2.c are different from the ones in the AP. I see that you've removed all functions except the bmi270_init from the bmi270.c file. and you've defined many more functions in the bmi2.c, which are not there in the API's bmi2.c file. I think I'm on a completely incorrect track right now. Using an API shouldn't have been this difficult. Is there some method I can do this the way it is supposed to be done? Edit: I tried to debug why the bmi_init function was returning -3 as rslt. turns out, in the function int8_t bmi2_sec_init(struct bmi2_dev *dev) in bmi2.c, there is: /* Read chip-id of the BMI2 sensor */
rslt = bmi2_get_regs(BMI2_CHIP_ID_ADDR, &chip_id, 1, dev);
if (rslt == BMI2_OK)
/* Validate chip-id */
if (chip_id == dev->chip_id)
/* Storing the chip-id value read from
* the register to identify the sensor
dev->chip_id = chip_id;
rslt = BMI2_E_DEV_NOT_FOUND;
} The issue is, when it reads the chip ID here, it reads it as 0x00. I have a hunch that the dummy byte configuration is not correct. Initially, when I was reading the chip ID using bmi_get_regs(), it required me to handle the extra SPI dummy byte in my reg read code. which shouldn't be the case if the mode is SPI.(the API has the appropriate code to handle that additional byte, if it's configured as SPI.) I think, initially, it is going ahead with dummy byte = 0, and then somewhere down the line, it is being reconfigured as 1. so, when it reads the first byte from the received buffer, it is the dummy byte, which is 0x00. I'm unsure how to solve this issue.
... View more
Hi, I have a few more doubts. Does this mean, that I could only use bmi270.c and that is all? because it doesn't look like so, as there are two functions missing in it. However, I can manually copy-paste them from bmi2.c to bmi270.c. These functions are: bmi2_get_gyro_cross_sense, and bmi2_sec_init. And does this also mean that the common.c is just an example? I have defined the hardware abstraction layer functions for the TIVA and spi in a separate file and am able to link them to the dev structure as required in bmi270.c. But, in order to read or write any register, I need the reg read functions which are in bmi2.c Can't the documentation include what the overall hierarchy of the various abstractions is?
... View more