hardfault called when interfacing LPC55s16-evk with BHI260AB over I2C

[prasheelbb8]

Setup

LPC55S16-EVK:

Configured FlexComm 4 to use I2C, PIO1_20 (SCL) PIO1_21(SDA), PIO0_7 (GPIO pin as Interrupt, works when configured as a PINT pin too)

Baudrate: 100K

BHI260AB:

Using a shuttle board which has a level translator to convert 3.3V i2c fro NXP to 1.8V i2c on BHI260AB.

Referring to the BHY2_API from github euler example, I changed the internal I2C read, write and interrupt related functions to use MCUXpresso SDK v2.10.1 I2C API's.

Normal operation

Using their bhy2cli app over the terminal, one should send 107804 bytes of firmware image over I2C, boot from RAM and retrieve the readings from the onboard sensor like getting the orientation and parsing them for euler angles. We want to use the same on our custom board that talks with the bhi260ab.

Issue

I have been successful in uploading and booting the RAM Program on the BHI260AB through the LPC55s16 board but the code stops with a hardfault as soon as I want to read the readings from the sensor.

On checking through a logic analyzer, the i2c on lpc55s16-evk definitely reads out the first orientation reading from the bhi260ab but then enters into system hardfault (attached excel sheet,

Way to read it -

- columns A to I: LPC55S16-EVK

- columns K to R: Standalone bosch

- column S: comparison of firmware bytes and data received between LPC and bosch side

- row 103218: From this row the firmware upload was successful and the read write commands from here are to boot the program on BHI260AB, enable the sensor, and get status and debug FIFO data.

- row 106408: including this batch of data read, everything is correct. Some of the false values in the registers is the timestamp data so it will be different. And from this row, it is actually the sensor data from sensor id 0x2C and the following 5 bytes are the data. 

- Registers 0xF5, 0xF7, 0xF8 are timestamp data and would be different.

Clearly, the struct variable, `bhy2.table[sensor_id].callback` is never registering the address of the parse_meta_event/parse_euler function that I send from the main() (L153 --> L1160 in bhy2.c). Even checked this at the memory level where the address for `dev->table[sensor_id].callback` 2000ffcc never gets assigned the addresses of these callbacks like for parse_meta_event, 0x2951 is never stored into 2000ffcc.

Has anyone ever faced such an issue? Even changed the compiler from GNU C99 to GNU C17 to see if any struct pointer/address issues are present.

Reached out to Bosch as well in this matter but any help would be greatly appreciated!

[prasheelbb8 · Accepted solution]

Update:

The primary reason behind this was the compiler Redlib. It has limitations w.r.t the stack memory allocation.

Configuring the compiler, assembler and linker to Newlib Nano (nohost) and increasing the end in stack memory to 0x2000 helped in compiling as well as debugging the code. We are able to hear from the bosch BHI260AB chip.

The caveat here being the configuration of this compiler and the integration of these bhy APIs leads to very minimal space left in the program_flash. In order to work our way through, we need to perform code optimization to -Os/-O3 through MCU Compiler settings.

[prasheelbb8]

Update:

Upon further debugging, we believe it is the use of pointers going on in the Bosch API's. They are according to ISO C99 standard and work with a bunch of compilers.

On NXP, Redlib compiler does not seem to accept this way of the Bosch APIs. Moreover, switching over to Newlib on LPC55S16-EVK is not helping as the code enters hardfault even before hitting the first line in main().

[xiangjun_rong]

Hi,

I have checked your Excel doc, there are incorrect reading data sporadically, Pls try to reduce the I2C baud-rate and have a try.

BR

XiangJun Rong

[prasheelbb8]

Hello XiangJun,

I am running at baud rate of 100K and it does not seem the problem, i.e regardless of the baudrate, the code enters hardfault. Sorry for misleading you on the excel sheet, this is how we read it -

Way to read the excel sheet -

- columns A to I: LPC55S16-EVK

- columns K to R: Standalone bosch

- column S: comparison of firmware bytes and data received between LPC and bosch side

- row 103218: From this row the firmware upload was successful and the read write commands from here are to boot the program on BHI260AB, enable the sensor, and get status and debug FIFO data.

- row 106408: including this batch of data read, everything is correct. Some of the false values in the registers is the timestamp data so it will be different. And from this row, it is actually the sensor data from sensor id 0x2C and the following 5 bytes are the data. 

- Registers 0xF5, 0xF7, 0xF8 are timestamp data and would be different.