Dear Dialog Support,
我们正在与新的Inventek ISM14585 module. We want to port the MSK firmware to this module, using BMI160 (and later add BMM150). On the MultiSensor DK I have successfully replaced the acc/gyro with BMI160 and got it running.
Now I have some trouble porting the firmware.
Observations:
(1)我不得不undef USE_SPI_FLASH_CONFIG,否则I got a hard fault (waiting for SPI to read the flash). I don't know what the problem could be. The internal flash of ISM14585 is a GigaDevice GD25D series.
(2) I have deactivated most routines of env. sensors and the magnetometer in the code. When I start the firmware, and connect with the IoT app, UART shows the following:
========IoT+ STARTED======== INFO: Sensors Initilization INFO: Sensors Suspend INFO: Adv Started, value:160 INFO: IoT+ Connected INFO: Sensors Initilization INFO: Sensors Suspend INFO: DWS cmd: 21 INFO: DWS cmd: 22 INFO: DWS cmd: 11 INFO: DWS cmd: 1 INFO: Sensors Started INFO: DWS cmd: 17 INFO: DWS cmd: 13 INFO: DWS cmd: 20 INFO: DWS cmd: 26
After this, nothing happens. The app does not show any sensor data.
Findings:
(A) I measured that the BMI160 interrupt is constantly high, it seems the DRDY interrupt is not working.
Apart from that, I see CS, CLK, MISO, MOSI without any abnormalities.
(B) In UM-B-101, appendix A, I discovered that the MultiSensor DK actually uses a secondary bootloader that takes care of some configuration steps; but it did not seem to me that it does anything crucial for BMI160 (whereas it does some configuration for the original acc/gyro).
In the ISM14585, OTP is burned with a secondary bootloader since the internal flash CS is mapped to P0_7 instead of P0_3 (thus it would not boot from in dev mode without this).
My Questions:
(1) What can be the reason that I don't see the interrupt from BMI160 going low?
(2) Is the special secondary bootloader necessary? Can I port the firmware by just flashing the resulting hex file into the flash?
Your help is very much appreciated.
BR Johannes
Hi Johannes,
Please let me know which GPIOs are connected to the BMI160 so I can run it on my side.
I am not a big fan of using the Sensor IoT tag firmware as a startingpoint for your application. You will be left with lots of halfway supported pieces of code that will end up biting you. A better approach would be to use the empty_peripheral_template project and slowly move pieces of code into that project.
/MHv
Hi MHv,
ad 1.:
GPIO mapping is trivial, SPI bus is shared with flash on the standard ports for CLK/MOSI/MISO, CS (P1_3) and DRDY/INT (P0_1) I have configured correctly. Initialization should work OOB with MultiSensor DK, since the DK is capable of operating with BMI160 (which we have verified).
ad 2.:
A secondary bootloader has been burned to OTP by the manufacturer Inventek. I will discuss with them why they have not done it as you suggested. Maybe it is a misunderstanding.
我知道如何配置SmartSnippets, after all I have the firmware running and advertising (booting from flash).
In UM-B-101 it is stated that the MS DK secondary bootloader [...]
Which is why I asked about the necessity of this specific bootloader. From looking into the code, I am under the impression that the bootloader does configure something for ICM42605, but not for the optionally populated BMI160.
For our previous prototype, that was based on the Murata ZY, we have ported the "old" IoT Sensor SDK, which as worked just fine. Certainly starting from scratch is a cleaner solution, but with limited manpower, stripping down an existing project is the faster approach...
BR Johannes
Hi Johannes,
The IMU initialization in the secondary bootloader is not important (I frankly have no idea why we placed it there), and I don't see any reference to the BMI160 in the code. Sorry for asking obvious questions, but I assume that you have wired the BMI160 exactly as it was connected in your multi sensor kit (using the same interrupt etc). I would also assume that you have correctly initialized the bus (in the secondary bootloader this was managed for the ICM IMU - including selction of the GPIOs).
I will reach out to you directly later today to help troubleshoot this.
/MHv
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:
(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
in the file sensors_interface.c shows that the interrupt is indeed being configured. A breakpoint in
then shows that the callback is never executed, although the pin goes HIGH. The pin is correctly configured according to our schematic:
[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 gme_johannes,
My apologies for the delay. I totally agree with MHv_Dialog and I think the best approach would be to use the empty_peripheral_template project and slowly move pieces of code into that project. However, I will the Team internally to get their feedback. I will get back to you as soon as possible.
Thanks, PM_Dialog
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
only registers P1 and P2 are checked. Then I saw tha in UM-B-101 page 20 it is stated:
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
Hi gme_johannes,
According to UM-B-101 document, the 585 MSK firmware extends the possibilities of interrupt handling in order to wake up. Currently this module supports interrupts in port 1 and 2 because port 0 is reserved for other scope. Keep in mind that 585 MSK is designed to work together with MSK hardware. Please take a look at Table 1 ofUM-B-101: DA14585 IoT Multi Sensor Development Kit Developer Guidedocument in order to check the port 0 assignment. In addition, if you check the source code of wkup_ad_cb(), you will see that is configured for port 1 and 2.
Thanks, PM_Dialog
Hi PM_Dialog,
as I've written in the second edit, I have solved the problem. It was unproblematic to get the interrupt on port 0, after all.
Thanks,
Johannes