We're working with a custom board based on the TI CC2640R2, and while we are able to fit the 8k config file into flash with the rest of the application, RAM is very limited, and we cannot integrate the BMI270 API, so we are basically driving the BMI270 at the register level through TI's SPI API.
We have managed to get the config file to load (INTERNAL_STATUS reports init_ok). This is with code running in the main firmware application. This product makes use of the CC26xx family's Sensor Contoller, which is a low-power auxiliary sub-system intended for simple sensor interfaces. Due to its limitations, we have to download the 8k config file using the main micro, then after the config file has been downloaded, actual gyro data acquisition is driven by the sensor controller.
While init completes, we are not getting any data from the gyro. After init completes, the main firmware has to release control of the SPI port so the Sensor Controller can take it over. The config file download uses a data rate of 10 MHz so it can be completed as quickly as possible, but the SPI data rate on the Sensor Controller is limited to 1.1 MHz. Would you expect this change in the SPI data rate after config file download to cause issues?
I found while working on the config file download that It appears the timing is very tight on the init sequence. If I code all the SPI transfers one immediately after the other, I can get the download to succeed (INTERNAL_STATUS reports init_ok). If I put the SPI transfers into a generic transfer function, introducing function call over head between each step, the download fails, and INTERNAL_ERROR reports "long processing time, processing halted". The CC26xx Sensor Controller has its own set of APIs to drive a SPI interface, and I'm wondering if it's too slow for the BMI270.
Once the config file is downloaded, can the BMI270 then be driven at a lower clock rate, with more latency between successive commands for gyro setup and data reads?
