Porting IoT MultiSensor to ISM14585 module

Hi MHv,

I have some more findings.

(1) The initialization seems to be correct, whatever the bootloader may do, the MS DK also configures the GPIOs correctly. GPIOs and SPI parameters are configured in set_pad_functions and iot_dk_spi_init:

void periph_init(void) { // Power up peripherals' power domain SetBits16(PMU_CTRL_REG, PERIPH_SLEEP, 0); while (!(GetWord16(SYS_STAT_REG) & PER_IS_UP)); SetBits16(CLK_16M_REG, XTAL16_BIAS_SH_ENABLE, 1); //rom patch patch_func(); //Init pads set_pad_functions(); // (Re)Initialize peripherals iot_dk_spi_init(ACCEL_CS_PORT, ACCEL_CS_PIN, SPI_XTAL_DIV_2);

(2) I observe the exepcted activity on MISO, MOSI, CLK, CS with an oscilloscope. SPI seems to be working fine.

(3) I observe that the BMI160 interrupt goes high (shows again that the BMI160 seems to be programmed correctly through SPI), and this seems to be were the problem starts. The firmware does not react to the interrupt.

Following the observation (3) I have inspected the behavior with Ozone (spoiler: I used it for the first time). A breakpoint in

void si_setup_interrupts(si_list_entity_t *ptr)

in the file sensors_interface.c shows that the interrupt is indeed being configured. A breakpoint in

void si_gpio_irq_cb(uint8_t port, uint32_t pin)

then shows that the callback is never executed, although the pin goes HIGH. The pin is correctly configured according to our schematic:

#define ACCEL_DRDY_PORT GPIO_PORT_0 #define ACCEL_DRDY_PIN GPIO_PIN_1 [...] GPIO_ConfigurePin(ACCEL_DRDY_PORT, ACCEL_DRDY_PIN,INPUT_PULLDOWN, PID_GPIO, false);

[edit; deleted a part that I now figured is normal and does not help to find the problem]

In your earlier response you indicated that you wanted to contact me, but I did not receive a notification or email. Do you require my contact info?

BR Johannes

edit:

(a) The same is true is I enable the wake on motion feature. I can observe that the device goes to sleep, the interrupt is low. When I move the sensor, the pin indeed goes high, but the firmware does not react to it.
(b) I have disabled sleep mode for those tests.

Dear Dialog Support,

I am still urgently waiting for an answer. What could be the reason for the interrupt not to work? How can I further investigate this issue with Ozone?

BR Johannes

Hi PM_Dialog,

considering how much our project has in common with the MultiSensor DK (everything except for: missing env sensors, different magnetometer, different pinout, different flash/PA), I hope that you can understand that I still favor the approach of stripping down/modifying the MultiSensor DK. I hope that you have some ideas how to investigate why I don't see the interrupt.
Maybe I should start with testing the interrupt functionality itself with the empty_peripheral_template.

BR Johannes

Hi PM_Dialog,

[any news? Any idea how I can solve this problem? Instructions for verification with Ozone would be great.]

edit:
After lenghty investigations in the code, I noticed that in

void wkup_ad_cb(void)

only registers P1 and P2 are checked. Then I saw tha in UM-B-101 page 20 it is stated:

Currently this module supports interrupts in port 1 and 2. This hardware configuration does not support other ports.

Can you please tell me - urgently - if interrupts on port 0 are not possible? What is the restriction here? SDK6? MultiSensor DK? DA14585?

edit2:
I have modified the callback function and just added according conditions for port 0, it seems to work without a flaw.
It isVERYunfortunate how long it took for me to find this out. Sure, it is documented... but I would never have guessed that the implementation is incomplete. I would be very curious to understand the reason.

BR Johannes