Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Communicating with BMI160 chip over SPI #31980

Closed
mejtejt opened this issue Feb 4, 2021 · 31 comments
Closed

Communicating with BMI160 chip over SPI #31980

mejtejt opened this issue Feb 4, 2021 · 31 comments

Comments

@mejtejt
Copy link

mejtejt commented Feb 4, 2021

Problem description

I have bosch bmi160 IMU on my custom board and cannot get SPI communication to work.

Detailed RFC

The hardware setup is as follows:
image

V40 and V41 are in the meantime replaced with 1k resistors. The right hand side of the screenshot is DARTMx6, and communication from that end is working fine, so I know BMI chip if fine (properly powered, etc).

The part of MCU where it is connected to SPI is as follows:
image

prj.conf file has the following configuration (gpio is also set to y in the part not seen here):
image

Device tree:
image

From the code it is called as this:
image

But I get the CS control inhibited error:
image

It if failing in this part of the code:
image

It looks like CS is not properly initialized/enabled (I guess it is not set as output). What am I missing and how do I achieve it?

Thanks for your help.

@mejtejt mejtejt added the RFC Request For Comments: want input from the community label Feb 4, 2021
@galak
Copy link
Collaborator

galak commented Feb 5, 2021

Glancing at the code I think the bmi160 driver doesn't support CS based on GPIO.

If you look at other sensor drivers you see blocks of code like in the init function:

#if DT_INST_SPI_DEV_HAS_CS_GPIOS(0)
        /* handle SPI CS thru GPIO if it is the case */
        data->cs_ctrl.gpio_dev = device_get_binding(
                DT_INST_SPI_DEV_CS_GPIOS_LABEL(0));
        if (!data->cs_ctrl.gpio_dev) {
                LOG_ERR("Unable to get GPIO SPI CS device");
                return -ENODEV;
        }

        data->cs_ctrl.gpio_pin = DT_INST_SPI_DEV_CS_GPIOS_PIN(0);
   ...

@mejtejt
Copy link
Author

mejtejt commented Feb 5, 2021

I looked at the other drivers, I see your point. There is no DT_INST_SPI_DEV_HAS_CS_GPIOS anywhwere inside of bmi160.c driver.

But my question is then: how do I setup SPI pins (MISO, MOSI, CLK) and CS properly? How do I synchronize CS and the communication? I would expect the driver to handle CS pin. How can this be achieved? What do I need to modify in my device tree? And are there any other modifications needed (eg. Kconfig file, etc). Thanks in advance.

@mejtejt
Copy link
Author

mejtejt commented Feb 5, 2021

Just an update. I can get a communication with the chip, but only after taking the power of the board and re-applying it. If the power to the board is present at all times, and I just flash MCU over JTAG, device cannot be found. This is something I still need to understand. Right now, I have no idea why is it behaving like this.

Dts looks like this (CS definitions are removed):
image

@galak
Copy link
Collaborator

galak commented Feb 5, 2021

But my question is then: how do I setup SPI pins (MISO, MOSI, CLK) and CS properly? How do I synchronize CS and the communication? I would expect the driver to handle CS pin. How can this be achieved? What do I need to modify in my device tree? And are there any other modifications needed (eg. Kconfig file, etc). Thanks in advance.

You need to add support in the driver to do the init for CS via GPIO.

@carlescufi carlescufi added area: SPI SPI bus Hardware Support area: Sensors Sensors and removed RFC Request For Comments: want input from the community labels Feb 5, 2021
@mejtejt
Copy link
Author

mejtejt commented Feb 8, 2021

I found where the problem lies in terrms of "sometimes init is successful, sometimes it is not":
image

The code is failing on reading chip ID:
image

But when I increase timeout on line 897 to 200us, it is fine. Can this timeout be increased as official release in bmi160.c file? I don't see a problem of having 1ms timeout, instead of 100us as it is now?

@mejtejt
Copy link
Author

mejtejt commented Feb 11, 2021

@galak , I have another problem for which I hope you can point me into the right direction. I want to configure trigger mode for BMI160. For that, my prj.conf file is set as:
image

Dts from before did not change, except I commented in int-gpios pin (it is connected to GPIOA, pin 2, as seen on one of the previous shots):
image

However, when I flash the code, I get the following output (as you can see, I added additonal LOGs inside of bmi160.c file):
image

Basically, it is failing at gpio_pin_configure inside of bmi160_trigger_mode_init. You can see what I modified here:
image

The weired parts are:
cfg->int_flags = 77
cfg->int_pin = 157;

They should be set to GPIO_ACTIVE_HIGH (0) and 2, respectively. Do you see anything I am doing wrong? Do I need to set something I have not set?

Thanks a lot for your help.

@galak
Copy link
Collaborator

galak commented Feb 11, 2021

@mejtejt can you remind me what SoC you are using?

@galak
Copy link
Collaborator

galak commented Feb 11, 2021

@mejtejt I'd suggest the following:

  • add -DCMAKE_EXPORT_COMPILE_COMMANDS=1 to cmake line. So you'll get something like cmake -DBOARD=frdm_k64f -DCMAKE_EXPORT_COMPILE_COMMANDS=1 ..
  • look in generated compile_commands.json for bmi160.c
  • than I suggest executing by hand the compile line for bmi160.c to get the preprocessor output:
    replace the -o CMakeFiles/drivers__sensor__bmi160.dir/bmi160.c.obj -c /home/galak/git/zephyr/drivers/sensor/bmi160/bmi160.c > bmi160.i with something like -E /home/galak/git/zephyr/drivers/sensor/bmi160/bmi160.c (path's need adjusting for your case)
  • Look at bmi160.i for int_flags and see what you are getting set.
  • Can you also report the output of zephyr/zephyr.dts from your build dir.

@mejtejt
Copy link
Author

mejtejt commented Feb 11, 2021

It is STM32L462VEI6. As for the other part, I will get back to you shortly.

@mejtejt
Copy link
Author

mejtejt commented Feb 11, 2021

Here is the output of zephyr/zephyr.dts
image

@mejtejt
Copy link
Author

mejtejt commented Feb 11, 2021

@galak , as for compiling, how do I tell it which compiler to use?

Looking at the compile_commands.json file, I get:
-o zephyr/drivers/sensor/bmi160/CMakeFiles/drivers__sensor__bmi160.dir/bmi160.c.obj -c /home/filip/GitRepositories/zephyrproject/zephyr/drivers/sensor/bmi160/bmi160.c"

So, I waas trying to do: /usr/bin/gcc -E /home/filip/GitRepositories/zephyrproject/zephyr/drivers/sensor/bmi160/bmi160.c -o ./bmi160.c.o -c.

But that returns:
image.

How do I compile bmi160.c manually? Which command I have to execute?

As for the dts above, it looks fine, right?

@galak
Copy link
Collaborator

galak commented Feb 11, 2021

What did the full line in compile_commands.json looks like?

@mejtejt
Copy link
Author

mejtejt commented Feb 11, 2021

{
  "directory": "/home/filip/GitRepositories/zephyrproject/greyp-zephyr-packages/build",
  "command": "/home/filip/zephyr-sdk-0.12.2/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc -DBUILD_VERSION=v2.5.0-rc3-72-g88725260e622 -DCORE_CM4 -DKERNEL -DSTM32L462xx -DUSE_FULL_LL_DRIVER -DUSE_HAL_DRIVER -D_FORTIFY_SOURCE=2 -D__LINUX_ERRNO_EXTENSIONS__ -D__PROGRAM_START -D__ZEPHYR_SUPERVISOR__ -D__ZEPHYR__=1 -I/home/filip/GitRepositories/zephyrproject/zephyr/include -Izephyr/include/generated -I/home/filip/GitRepositories/zephyrproject/zephyr/soc/arm/st_stm32/stm32l4 -I/home/filip/GitRepositories/zephyrproject/zephyr/lib/libc/newlib/include -I/home/filip/GitRepositories/zephyrproject/zephyr/drivers -I/home/filip/GitRepositories/zephyrproject/zephyr/soc/arm/st_stm32/common/. -I/home/filip/GitRepositories/zephyrproject/zephyr/soc/arm/st_stm32/common -I/home/filip/GitRepositories/zephyrproject/zephyr/subsys/net/lib/sockets/. -I/home/filip/GitRepositories/zephyrproject/modules/hal/cmsis/CMSIS/Core/Include -I/home/filip/GitRepositories/zephyrproject/modules/hal/stm32/stm32cube/stm32l4xx/soc -I/home/filip/GitRepositories/zephyrproject/modules/hal/stm32/stm32cube/stm32l4xx/drivers/include -I/home/filip/GitRepositories/zephyrproject/modules/hal/stm32/stm32cube/stm32l4xx/drivers/include/Legacy -I/home/filip/GitRepositories/zephyrproject/modules/hal/stm32/stm32cube/common_ll/include -I/home/filip/GitRepositories/zephyrproject/greyp-zephyr-packages/drivers/rtc/m41t62/. -I/home/filip/GitRepositories/zephyrproject/greyp-zephyr-packages/modules/nanopb/.    -Os -imacros /home/filip/GitRepositories/zephyrproject/greyp-zephyr-packages/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -mcpu=cortex-m4 -mthumb -mabi=aapcs -imacros /home/filip/GitRepositories/zephyrproject/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wno-address-of-packed-member -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=/home/filip/GitRepositories/zephyrproject/greyp-zephyr-packages/applications/cyklaer/impl=CMAKE_SOURCE_DIR -fmacro-prefix-map=/home/filip/GitRepositories/zephyrproject/zephyr=ZEPHYR_BASE -fmacro-prefix-map=/home/filip/GitRepositories/zephyrproject=WEST_TOPDIR -ffunction-sections -fdata-sections -specs=nano.specs -std=c99 -o zephyr/drivers/sensor/bmi160/CMakeFiles/drivers__sensor__bmi160.dir/bmi160.c.obj   -c /home/filip/GitRepositories/zephyrproject/zephyr/drivers/sensor/bmi160/bmi160.c",
  "file": "/home/filip/GitRepositories/zephyrproject/zephyr/drivers/sensor/bmi160/bmi160.c"
},

@galak
Copy link
Collaborator

galak commented Feb 11, 2021

So try:

/home/filip/zephyr-sdk-0.12.2/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc -DBUILD_VERSION=v2.5.0-rc3-72-g88725260e622 -DCORE_CM4 -DKERNEL -DSTM32L462xx -DUSE_FULL_LL_DRIVER -DUSE_HAL_DRIVER -D_FORTIFY_SOURCE=2 -D__LINUX_ERRNO_EXTENSIONS__ -D__PROGRAM_START -D__ZEPHYR_SUPERVISOR__ -D__ZEPHYR__=1 -I/home/filip/GitRepositories/zephyrproject/zephyr/include -Izephyr/include/generated -I/home/filip/GitRepositories/zephyrproject/zephyr/soc/arm/st_stm32/stm32l4 -I/home/filip/GitRepositories/zephyrproject/zephyr/lib/libc/newlib/include -I/home/filip/GitRepositories/zephyrproject/zephyr/drivers -I/home/filip/GitRepositories/zephyrproject/zephyr/soc/arm/st_stm32/common/. -I/home/filip/GitRepositories/zephyrproject/zephyr/soc/arm/st_stm32/common -I/home/filip/GitRepositories/zephyrproject/zephyr/subsys/net/lib/sockets/. -I/home/filip/GitRepositories/zephyrproject/modules/hal/cmsis/CMSIS/Core/Include -I/home/filip/GitRepositories/zephyrproject/modules/hal/stm32/stm32cube/stm32l4xx/soc -I/home/filip/GitRepositories/zephyrproject/modules/hal/stm32/stm32cube/stm32l4xx/drivers/include -I/home/filip/GitRepositories/zephyrproject/modules/hal/stm32/stm32cube/stm32l4xx/drivers/include/Legacy -I/home/filip/GitRepositories/zephyrproject/modules/hal/stm32/stm32cube/common_ll/include -I/home/filip/GitRepositories/zephyrproject/greyp-zephyr-packages/drivers/rtc/m41t62/. -I/home/filip/GitRepositories/zephyrproject/greyp-zephyr-packages/modules/nanopb/.    -Os -imacros /home/filip/GitRepositories/zephyrproject/greyp-zephyr-packages/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -mcpu=cortex-m4 -mthumb -mabi=aapcs -imacros /home/filip/GitRepositories/zephyrproject/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wno-address-of-packed-member -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=/home/filip/GitRepositories/zephyrproject/greyp-zephyr-packages/applications/cyklaer/impl=CMAKE_SOURCE_DIR -fmacro-prefix-map=/home/filip/GitRepositories/zephyrproject/zephyr=ZEPHYR_BASE -fmacro-prefix-map=/home/filip/GitRepositories/zephyrproject=WEST_TOPDIR -ffunction-sections -fdata-sections -specs=nano.specs -std=c99 -E /home/filip/GitRepositories/zephyrproject/zephyr/drivers/sensor/bmi160/bmi160.c > foo.i"

@mejtejt
Copy link
Author

mejtejt commented Feb 11, 2021

Step forward, but it can't find syscall_list.h.

filip@filip-ThinkPad-L560 ~/GitRepositories/zephyrproject/zephyr/drivers/sensor/bmi160 (master) $ /home/filip/zephyr-sdk-0.12.2/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc -DBUILD_VERSION=v2.5.0-rc3-72-g88725260e622 -DCORE_CM4 -DKERNEL -DSTM32L462xx -DUSE_FULL_LL_DRIVER -DUSE_HAL_DRIVER -D_FORTIFY_SOURCE=2 -D__LINUX_ERRNO_EXTENSIONS__ -D__PROGRAM_START -D__ZEPHYR_SUPERVISOR__ -D__ZEPHYR__=1 -I/home/filip/GitRepositories/zephyrproject/zephyr/include -Izephyr/include/generated -I/home/filip/GitRepositories/zephyrproject/zephyr/soc/arm/st_stm32/stm32l4 -I/home/filip/GitRepositories/zephyrproject/zephyr/lib/libc/newlib/include -I/home/filip/GitRepositories/zephyrproject/zephyr/drivers -I/home/filip/GitRepositories/zephyrproject/zephyr/soc/arm/st_stm32/common/. -I/home/filip/GitRepositories/zephyrproject/zephyr/soc/arm/st_stm32/common -I/home/filip/GitRepositories/zephyrproject/zephyr/subsys/net/lib/sockets/. -I/home/filip/GitRepositories/zephyrproject/modules/hal/cmsis/CMSIS/Core/Include -I/home/filip/GitRepositories/zephyrproject/modules/hal/stm32/stm32cube/stm32l4xx/soc -I/home/filip/GitRepositories/zephyrproject/modules/hal/stm32/stm32cube/stm32l4xx/drivers/include -I/home/filip/GitRepositories/zephyrproject/modules/hal/stm32/stm32cube/stm32l4xx/drivers/include/Legacy -I/home/filip/GitRepositories/zephyrproject/modules/hal/stm32/stm32cube/common_ll/include -I/home/filip/GitRepositories/zephyrproject/greyp-zephyr-packages/drivers/rtc/m41t62/. -I/home/filip/GitRepositories/zephyrproject/greyp-zephyr-packages/modules/nanopb/.    -Os -imacros /home/filip/GitRepositories/zephyrproject/greyp-zephyr-packages/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -mcpu=cortex-m4 -mthumb -mabi=aapcs -imacros /home/filip/GitRepositories/zephyrproject/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wno-address-of-packed-member -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=/home/filip/GitRepositories/zephyrproject/greyp-zephyr-packages/applications/cyklaer/impl=CMAKE_SOURCE_DIR -fmacro-prefix-map=/home/filip/GitRepositories/zephyrproject/zephyr=ZEPHYR_BASE -fmacro-prefix-map=/home/filip/GitRepositories/zephyrproject=WEST_TOPDIR -ffunction-sections -fdata-sections -specs=nano.specs -std=c99 -E /home/filip/GitRepositories/zephyrproject/zephyr/drivers/sensor/bmi160/bmi160.c > foo.i
In file included from /home/filip/GitRepositories/zephyrproject/zephyr/include/kernel_includes.h:31,
                 from /home/filip/GitRepositories/zephyrproject/zephyr/include/kernel.h:17,
                 from /home/filip/GitRepositories/zephyrproject/zephyr/include/init.h:11,
                 from /home/filip/GitRepositories/zephyrproject/zephyr/drivers/sensor/bmi160/bmi160.c:13:
/home/filip/GitRepositories/zephyrproject/zephyr/include/syscall.h:11:10: fatal error: syscall_list.h: No such file or directory
   11 | #include <syscall_list.h>
      |          ^~~~~~~~~~~~~~~~
compilation terminated.
filip@filip-ThinkPad-L560 ~/GitRepositories/zephyrproject/zephyr/drivers/sensor/bmi160 (master) $

@galak
Copy link
Collaborator

galak commented Feb 11, 2021

Do a full build first, than re-run the command.

@mejtejt
Copy link
Author

mejtejt commented Feb 11, 2021

Unfortunately, it did not help. I ran west build -v --board=cyklaer_prototype applications/cyklaer/impl --pristine and then the command above, still the same.

Do you have a possibility to try it out on STM32L462 (or similar board) by yourself?

@galak
Copy link
Collaborator

galak commented Feb 11, 2021

Unfortunately, it did not help. I ran west build -v --board=cyklaer_prototype applications/cyklaer/impl --pristine and then the command above, still the same.

Do you have a possibility to try it out on STM32L462 (or similar board) by yourself?

Are you able to push your code to your github account?

I tried the following on disco_l475_iot1:

diff --git a/boards/arm/disco_l475_iot1/disco_l475_iot1.dts b/boards/arm/disco_l475_iot1/disco_l475_iot1.dts
index f695560e09..9865db44e3 100644
--- a/boards/arm/disco_l475_iot1/disco_l475_iot1.dts
+++ b/boards/arm/disco_l475_iot1/disco_l475_iot1.dts
@@ -121,6 +121,14 @@
 &spi1 {
        pinctrl-0 = <&spi1_sck_pa5 &spi1_miso_pa6 &spi1_mosi_pa7>;
        status = "okay";
+
+       bmi160@0 {
+               compatible = "bosch,bmi160";
+               reg = <0>;
+               label = "BMI160";
+               spi-max-frequency = <800000>;
+               int-gpios = <&gpioa 2 GPIO_ACTIVE_HIGH>;
+       };
 };

and see:

static struct bmi160_data bmi160_data_0; static const struct bmi160_cfg bmi160_cfg_0 = { .gpio_port = "GPIOA", .int_pin = 2, .int_flags = 0, .reg_io = &bmi160_reg_io_spi, .bus_label = "SPI_1", .bus_cfg = { .spi_cfg = (&(struct spi_config) { .operation = ((8) << (5)), .frequency = 800000, .slave = 0, }), }, }; const __attribute__((__aligned__(__alignof(struct device)))) struct device __device_dts_ord_334 __attribute__((__used__)) __attribute__((__section__(".device_" "POST_KERNEL" "90"))) = { .name = "BMI160", .config = (&bmi160_cfg_0), .api = (&bmi160_api), .data = (&bmi160_data_0), }; _Static_assert(sizeof("\"BMI160\"") <= 48, "" "DEVICE_GET_NAME(\"BMI160\")" " too long"); static const __attribute__((__aligned__(__alignof(struct init_entry)))) struct init_entry __init___device_dts_ord_334 __attribute__((__used__)) __attribute__((__section__(".init_" "POST_KERNEL" "90"))) = { .init = (bmi160_init), .dev = ((&__device_dts_ord_334)), };

where .int_pin and .int_flags look good.

@mejtejt
Copy link
Author

mejtejt commented Feb 12, 2021

@galak, I have to ask for permission rights, to see if I can pust the code to github.
In the meantime, I have another question for the error above.

image

As you can see, the "missing" include is in the /home/filip/GitRepositories/zephyrproject/zephyr/build/zephyr/include/generated folder. So, it exists. Is there a location from where I have to run the compile command for build to succeed?

@mejtejt
Copy link
Author

mejtejt commented Feb 12, 2021

@galak , let me reduce the code to the minimum needed to reproduce the error, and then I will push the code to my github account. I will let you know when I do so. Thanks.

@galak
Copy link
Collaborator

galak commented Feb 12, 2021

@mejtejt are you on the zephyr slack? Might be easier to chat there.

I normally use cmake directly and not west for my builds. What I'd suggest is this:

mkdir -p applications/cyklaer/impl/build
cd applications/cyklaer/impl/build
cmake -DBOARD=cyklaer_prototype -DCMAKE_EXPORT_COMPILE_COMMANDS=1 ..
make

you should than be able to do the preprocessor command.

@mejtejt
Copy link
Author

mejtejt commented Feb 13, 2021

@galak, I am not yet on zephyr slack, but I will create an account on Monday and will contact you then on slack.

In a meanwhile, your last instructions helped me a lot and I was able to manually compile bmi160 driver and got the preprocessor output. The line of interest to us looks like this:
static struct bmi160_data bmi160_data_0; static const struct bmi160_cfg bmi160_cfg_0 = { .gpio_port = "GPIOA", .int_pin = 2, .int_flags = 0, .reg_io = &bmi160_reg_io_spi, .bus_label = "SPI_1", .bus_cfg = { .spi_cfg = (&(struct spi_config) { .operation = ((8) << (5)), .frequency = 8000000, .slave = 0, }), }, }; const

It it exactly what it is supposed to be like. Which is a good and a bad thing at the same time. Good because output is as we want/expect it to be. Bad because it does not explain why the problem is happening then (i.e. how come does the bmi160_trigger_mode_init function gets different numbers.). I will have to add log output to bmi160_trigger.c again and verify the inf_flags and int_pin are the same as when I had problems. If the numbers are different than what says in bmi160.txt, then I don't know what is the next step. Complete file output is attached, just in case you find some other info there needed/suspicious.

bmi160.txt

I do not have the board next to me, I will try flashing the board on Monday and see if I get the same problems as before.

PS. What makes using cmake directly instead of west build better? Also, is using west flash OK or make flash makes a difference? On the official webpage at least says these two commands are identical. Thanks a lot for all your help.

@galak
Copy link
Collaborator

galak commented Feb 13, 2021

PS. What makes using cmake directly instead of west build better? Also, is using west flash OK or make flash makes a difference? On the official webpage at least says these two commands are identical. Thanks a lot for all your help.

west manages more things for you so its better for most people. I've been working on zephyr before west was around so I haven't really fully switched over my personal workflow to be fully west based. I don't believe there is any real difference between make flash and west flash at the point your at. make flash will eventually call west flash for you. I think make flash will also ensure your build is up to date before flashing.

@mejtejt
Copy link
Author

mejtejt commented Feb 15, 2021

@galak , first of all, how do I find you on zephyr slack? I created an account, but cannot find you to DM you.

In a meanwhile, let me share what I have found. I added more logs into the bmi160.c and bmi160_trigger.c files. They are as seen below.

At the beginning of the bmi160_init function:
image

Then just before bmi160_trigger_mode_init is called:
image

And the last call within bmi160_trigger_mode_init, the first thing in the function:
image

Look at the output I get:
image

So, what we were trying to establish before, is actually OK. int_flags, int_pin are setup correctly, and once bmi160_trigger_mode_init is called, everything falls apart (GPIO controller becomes SPI controller, etc.). This is the behaviour given the following prj.conf setup:
image

When I move the body of the bmi160_trigger_mode_init code in the bmi160_init function, things work (OK, not everything is included, but gpio_configure is fine).
image

image

What do you reckon of that?

@mejtejt
Copy link
Author

mejtejt commented Feb 15, 2021

I have reduced the code to a minimum needed for BMI initialization.

# C Library
CONFIG_NEWLIB_LIBC=y

# C++ configuration
CONFIG_CPLUSPLUS=y
CONFIG_LIB_CPLUSPLUS=y
CONFIG_STD_CPP14=y

# UART3 -> console output
# make sure CONFIG_CONSOLE and CONFIG_UART_CONSOLE is enabled
# CONFIG_CONSOLE=n
# CONFIG_UART_CONSOLE=n
CONFIG_PRINTK=y
CONFIG_STDOUT_CONSOLE=y # std::cout and printf output...
CONFIG_UART_CONSOLE_ON_DEV_NAME="UART_3"  # ...goes to UART_3

CONFIG_LOG=y

# IMU configuration; CONFIG_SENSOR must be enabled
CONFIG_SPI=y
CONFIG_BMI160=y
CONFIG_SENSOR=y
CONFIG_BMI160_TRIGGER_OWN_THREAD=y
CONFIG_SENSOR_LOG_LEVEL_DBG=y

But still, this did not make any difference:
image

I am slowly running out of ideas what do/change/modify...

@galak
Copy link
Collaborator

galak commented Feb 16, 2021

@galak , first of all, how do I find you on zephyr slack? I created an account, but cannot find you to DM you.

what's your slack username?

@mejtejt
Copy link
Author

mejtejt commented Feb 17, 2021

@galak what's your slack username?: greyp

@galak
Copy link
Collaborator

galak commented Feb 17, 2021

@galak what's your slack username?: greyp

Are you sure you joined the correct slack? Not seeing you on the Zephyr slack, the invite is here:

https://tinyurl.com/y5glwylp

@mejtejt
Copy link
Author

mejtejt commented Feb 17, 2021

I followed the instructions again from your link.

image

Did I to everything correctly?

@gudnimg
Copy link
Contributor

gudnimg commented Mar 11, 2021

Could this be a linker script issue?

@github-actions
Copy link

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants