SDK15 Invensense MPU9250

[cyberluke]

Hi, we switched from your competition to your platform. I know you wrote somewhere that you cannot provide examples for every sensor out there. But your Nordic Dev Zone is a bit messy, information cluttered everywhere. And soon, information is also outdated by your own updates.

If we would talk about motion sensors, I know there are like only two manufacturers: Invensense & Bosch.

Your competition has better community and also the owners themselves care more and provide basic examples on everything. I'm not asking you to do so. Just motion sensors, there is not many vendors and you have 50+ similar questions about motion sensors. It would be good, responsible, western EU style behavior, if your management would get some feedback from community managers. If so many people asking about issues or examples. You can have better ROI and save resources here, if you would, by all the years, provide some, even basic example. You have MPU in your documentation, but that does not stand for motion processing unit, it is some memory protection unit instead (only adds to confusion when googling).

We have met on CES at Las Vegas, you ask for some feedback, how to get better than competition. Your competition have better examples of how easy is to use their product. How good is time to market. Here I see only messy forum and customer rant about the same thing again & again and it is more than 1 year.

And before you will send here the unofficial Michael's github, I want to say that it was for SDK14. Not for SDK15. Next it does not use Invensense DMP driver.

I want to use eDMP motion driver by Invensense. Read quaternion (4D vector) and use their pipeline and configuration. Because, unlike Bosch with second ARM coprocessor, Invensense requires to load their driver in your firmware memory, in order to get these data. You can find many examples on Sparkfun, Adafruit, not to mention Arduino community itself. Also other ARM vendors provide at least one example.

I'm not asking you provide examples on every sensor out there. Just, when it comes to market share, there is only Invensense and Bosch with MPUs. That would be quite basic bluetooth beacon example in 2019.

So my question is: can I get SDK15 working with MPU9250 using DMP? On various boards including ESP, NXP, Arduino, it is really a matter of minutes and then companies, your customers, can focus on developing the product and time to market is acceptable. Here with Nordic, my experience so far, is that the community is not exchanging projects as it should and Nordic company is not doing anything to bring more customers on their platform. What took me one day on other platforms, is impossible to accomplis on SDK15.

I think it is start of 2019 and time to rethink this whole community / customer / startup / manufacturers strategy.

[Jørgen Holmefjord]

Hi,

Thank you for your feedback, I will forward it to the relevant departments. 

In general, we get good feedback on the support we provide, and the information available in the community. If you have specific issues with integrating a driver with the SDK, we will help you as best we can. What we normally will not do is to fully integrate any driver with the SDK on request from a customer, without the customer doing any effort to do some work himself.

Like you say, Martin's examples on GitHub is written for SDK 14.2.0, but it should not be difficult to port these to run with SDK 15.2.0 (I have done this myself in the past).

The DPM driver is used in the Thingy:52 firmware, but this is based on SDK 13.0.0 (again, should not be difficult to port to SDK 15.2.0).

I would recommend that you post a new case with the specific issues you are facing by integrating the driver with SDK 15.2.0, and one of our application engineers will help you solve your issues.

Best regards,
Jørgen

[cyberluke]

Ok, code snippet inserted. Uploading image still not working. I'm on Google Chrome / Windows 10. I hit File Upload. Choose file (jpg screenshot) from my PC. It will not save it in the form and it automatically reopens Choose file window in infinite way. Looks like JavaScript issue on your website.

[cyberluke]

Running WinMerge (diff) on .cproject file for NRF52 and NRF52840 examples shows only different directives:

S132:S140
NRF52832_XXAA:NRF52840_XXAA
NRF52:NRF52_SERIES

So the only other difference here can be EHAL implementation for NRF52 and NRF52840 or I'm lost.

[Nguyen Hoan Hoang]

I see your problem.  Your button pins are assigned to the pins for the 32KHz crystal.  That's why BLE does not work.  It disabled the crystal used by softdevice.  If you don't have the crystal, you need to configure the softdevice to use the internal RC.  

[cyberluke]

I set up these pins just recently. The problem persisted. Even I set pins like Nordic DK (13, 14) no change. But at least I know the direction to go. I use EVK-NINA B3 board (NINA B-301 OpenCPU S140). It has slightly different pinout than Nordic DK, but it is still DK, so it should contain XTAL.

[cyberluke]

XTAL in your BLE example is set correctly according to nRF5_SDK\examples\ble_peripheral\ble_app_uart\pca10056\s140\config\sdk_config.h, so the only thing I can check is pin layout. Which I check before, but lets double check.

[cyberluke]

My Pin layout is same like here: https://os.mbed.com/media/uploads/MACRUM/evk-nina-b1_-ble-------_-------.pdf ...I did set also LED pins 1, 7, 8. I'm checking the rest.

[cyberluke]

How to achieve the "multi-archtecture multi-platform Hardware Abstraction Library" mentioned on EHAL page? Your Uarts BLE demo is using:

#include "blueio_board.h"

#include "custom_board.h"

#include "board.h"

Both custom_board.h and board.h includes blueio_board.h again inside themselves. How to get rid of blueio pins completely and provide my own definition? I think this project, and maybe others, need rewrite of board.h. Hopefully put it in EHAL_BOARDS new project or put it in EHAL project and include BlueIO, Nordic DK, Ublox DK, etc. Right now I have to rewrite blueio_board.h

[cyberluke]

The only difference I found when building NRF52 (S132) and NRF52840 (S140) is this folder:

EHAL\ARM\Nordic\nRF52\src\

vs

EHAL\ARM\Nordic\nRF52840\src\

But NRF52 project works. NRF52840 project does not work. And S140 example from official NRF5 SDK works the best (will discover & connect).

[Nguyen Hoan Hoang]

The include of "... board.h" does not matter for the abstraction.  You pin assignment in the data structure in  your code.  It is not hardcoded.  Look on top of main.  Everything is in the declaration/assignment of config.  Look other examples like blinky, UartPrbsTest.   The examples in EHAL\exemples for instance work in nRF5x, LPC11xx same code only need to change the pin map in the config structure on the top of main.  The same UART code also works in OSX. 

Here is how the abstraction works.  Lets have 2 interface SPI and I2C and the MPU-9250.

SPI g_SpiInterf;

I2C g_I2cInterf;

AgmMpu9250 g_MotSensor;

Assuming we already initialized the interfaces

To Init the MPU to work with SPI

g_MotSensor.Init(MotCfgData, &g_SpiInterf);

Want the Mpu to work with I2C instead

g_MotSensor.Init(MotCfgData, &g_I2cInterf);

here this is compiled with s140 pin mapped to your board.  I tested it on the Nordic DKUartBleDemo.hex

[cyberluke]

Your hex build behaves exactly like the one I build from NRF52 folder. Discovery works, I see UARTDemo device. But NRF Toolbox cannot connect, because it will not find required service characteristics.

Now, because NRF5 SDK examples built for Segger Studio works, I suspect my problem will be something with sdk_config.h and some new nrfx directives and the fact I use SDK 15.2. What version you use, please? SDK 15.0 ?

[cyberluke]

For example your nrf52840_xxaa.ld containts FLASH (rx) : ORIGIN = 0x00000, but correct from NRF5 SDK for NRF52840 is FLASH (rx) : ORIGIN = 0x26000. I did also flash softdevice_s140.hex separately in NrfGo Studio.