Sensor Fusion 5.0 K22F example project not working

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Sensor Fusion 5.0 K22F example project not working

Jump to solution
1,465 Views
danielnagy
Contributor II

Dear Support and Forum Members,

 

I have some trouble making the Sensor Fusion library work on my FRDM-K22F board. The 5.0 version of the library has two types of example projects for the K22F: MQXLite and "Bare Board". The Bare Board version compiles and runs fine, but not the MQXLite variant. Here is what happens:

- When I import the example project to Kinetis Design Studio, no debug configuration appears to that project. For any other project I create or import, there is a corresponding debug configuration, but not for the K22F MQXLite Sensor Fusion example project, which is strange. This way, I cannot run (debug) the project by default.

- If I create a debug configuration on my own, the project compiles and is uploaded to the board. However, it does not run properly: it either 'crashes' immediately (gets stuck with PE_DEBUGHALT() or in dispatch.s) or I just see the red LED lit on the board.

- I have discovered that in the source file 'drivers.h', the I2C address for the FXOS8700 sensor is wrong: it is 0x1E instead of 0x1C. I have changed this and recompiled, but the same issue persist.

 

Could you please advise me on this issue? Here is some additional information:

- I have not changed the board or the example project in any way except for correcting the sensor's I2C address in 'drivers.h'.

- I have tested the project with two instances of the K22F board, but same issue with both of them.

- The Bare Board version of the library works fine.

- I have previously ported the 4.22 version of the library to the K22F board and that works fine.

- KDS version: 3.2

- I use simple USB connection with OpenOCD to debug.

 

At this point I am pretty clueless as I expected the example project to have been tested and to work fine. Any guidance would be highly appreciated. Thank you for your help!

 

Thanks and regards

Daniel

Labels (1)
1 Solution
929 Views
michaelestanley
NXP Employee
NXP Employee

Daniel,

Over the last couple of years, the sensor's team has had some issues with debug configurations.  So we often strip them out of projects before shipping the kit (on purpose).  The assumption there being that user's can create a configuration which matches their hardware needs.

As to your other problem, would I be correct in guessing that you have a K22F board, but no sensor shield, and are therefore using the 8700 sensor on the K22F?  All of the projects under the "FSFK" subdirectory require a sensor shield to build and run "out of the box".  This is because the default configuration builds all six sensor fusion algorithms, including 9-axis accel/mag/gyro.  The gyro isn't available on the K22F, so the project will hang.  You saw an "error" in I2C address because the 8700 on the K22F is at a different address than the one on the shield boards.  The address is correct for the shield implementation (yes, we DO test all our standard configurations).

Try this, go into build.h and find:

// normally all enabled: degrees of freedom algorithms to be executed

#define COMPUTE_1DOF_P_BASIC  // 1DOF pressure (altitude) and temperature: (pressure)

#define COMPUTE_3DOF_G_BASIC  // 3DOF accel tilt: (accel)

#define COMPUTE_3DOF_B_BASIC  // 3DOF mag eCompass (vehicle): (mag)

#define COMPUTE_3DOF_Y_BASIC  // 3DOF gyro integration: (gyro)

#define COMPUTE_6DOF_GB_BASIC  // 6DOF accel and mag eCompass: (accel + mag)

#define COMPUTE_6DOF_GY_KALMAN  // 6DOF accel and gyro (Kalman): (accel + gyro)

#define COMPUTE_9DOF_GBY_KALMAN  // 9DOF accel, mag and gyro (Kalman): (accel + mag + gyro)

and change them to:

// normally all enabled: degrees of freedom algorithms to be executed

//#define COMPUTE_1DOF_P_BASIC  // 1DOF pressure (altitude) and temperature: (pressure)

#define COMPUTE_3DOF_G_BASIC  // 3DOF accel tilt: (accel)

#define COMPUTE_3DOF_B_BASIC  // 3DOF mag eCompass (vehicle): (mag)

//#define COMPUTE_3DOF_Y_BASIC  // 3DOF gyro integration: (gyro)

#define COMPUTE_6DOF_GB_BASIC  // 6DOF accel and mag eCompass: (accel + mag)

//#define COMPUTE_6DOF_GY_KALMAN  // 6DOF accel and gyro (Kalman): (accel + gyro)

//#define COMPUTE_9DOF_GBY_KALMAN  // 9DOF accel, mag and gyro (Kalman): (accel + mag + gyro)

That will disable all gyro and altimeter related build options.

Regards,

Mike

View solution in original post

0 Kudos
8 Replies
929 Views
javierhernande1
Contributor IV

Thanks you for clarification,

I edit the code of FSFK-K64F project to experiment with PE, I add a component to the blue led, and disable the component of green led, I changed the code a bit in task file and now instead of flashing the green led, flashes the blue led. Something very simple. I did not want to go deeper because I have seen that it will no longer use PE.

I want to do a KDS project  for the FRDM-K64F that can expose the data from the sensors, FXOS8700 and FXAS21002C and others I would add externally. Later, via SPI, to be able to communicate with FRDM-K64F from a microprocessor to read the data.

To do this you think I should use Processor Expert or KSDK_2.0?

Did you download the sensor fusion toolbox to view the fusion outputs?

I don't use Windows, only Linux. I tried once with Sensor Fusion Toolbox in other machine to prove that FRDM-K64F-AGM01 was all right, but not the FSFK-K64F project.

Best regards,

Javier

0 Kudos
929 Views
michaelestanley
NXP Employee
NXP Employee

Javier,

As you noted, Processor Expert support is slowly going away.  We have no immediate plans to remove the Version 5.00 (PE-based) sensor fusion release from the web, even after the 7.00 (KSDK-version) is released.  So you should be OK using it in the short to medium timeframe.  Once the V7.00 is online (again, planned for next month), I'll definately recommend everyone switch over.  The updated library has a number of features that I think make it more attractive to use.  See other posts in this space for details there.

We don't have a Linux version of the Sensor Fusion Toolbox.  So you are out of luck there.

929 Views
javierhernande1
Contributor IV

Thanks Mike,

Sensor Fusion Toolbox use dotNetFramework 4. With winetricks is possible to install but in a 32 environment, I have a 64bits OS. You are right, I'm out of luck :smileyhappy:

Android apk is ofuscate with Proguard?

Best regards,

Javier

0 Kudos
929 Views
javierhernande1
Contributor IV

Hello!,

The gyro isn't available on the K22F, so the project will hang.  You saw an "error" in I2C address because the 8700 on the K22F is at a different address than the one on the shield boards.

Yes, I have FRDM-K64F-AGM01 and FXOS8700 I2C address is diferent, is 0x1E.

I have imported all projects KSDK_2.0 but I find none dealing about Sensor Fusion.

I have tried FSFK_K64F project, wich I found inside FreescaleSensorFusionRevision5 folder, works although I could not see the data, I do not know how to see them, with minicom are only strange characters.

FSFK-K64F use MQXlite but MQXlite use Processor Expert  which is no longer being actively developed.

MQX Lite Real-Time Operating System (RTOS)|NXP

MQX Lite is packaged as a component for Processor Expert, which is no longer being actively developed. Please consider using the Kinetis Software Development Kit which includes support for the latest Kinetis devices.

I was reading the XSFLK_DS but is about MQXlite.  http://cache.nxp.com/files/sensors/doc/data_sheet/XSFLK_DS.pdf

Is there information on using Sensor Fusion without PE with KDS 3.2.0 + KSDK_2.0?

Best regards,

Javier

0 Kudos
929 Views
michaelestanley
NXP Employee
NXP Employee

Javier,

KSDK 2.0 is not yet supported by the sensor fusion library.  We expect to release a version that is next month.  The FSFK-K64F project is the right one to use.  Did you download the sensor fusion toolbox to view the fusion outputs?

Mike

929 Views
danielnagy
Contributor II

Dear Michael,

Thank you very much for your quick response. Yes, I am using the board without a sensor shield. I seem to have forgotten completely that the example projects apply to configurations with sensor boards and that build.h has to be changed accordingly if no shield is used. I have made the changes you suggested and it works fine now!

My sincere apologies for saying that the code was erroneous or has not been tested. Obviously, it was my thoughtlessness forgetting about configuring build.h. Sorry.

Thanks for your support!

Best regards

Daniel

0 Kudos
929 Views
michaelestanley
NXP Employee
NXP Employee

Daniel,

No apologies necessary.  I'm glad you are up and running again.

Best regards,

Mike

0 Kudos
930 Views
michaelestanley
NXP Employee
NXP Employee

Daniel,

Over the last couple of years, the sensor's team has had some issues with debug configurations.  So we often strip them out of projects before shipping the kit (on purpose).  The assumption there being that user's can create a configuration which matches their hardware needs.

As to your other problem, would I be correct in guessing that you have a K22F board, but no sensor shield, and are therefore using the 8700 sensor on the K22F?  All of the projects under the "FSFK" subdirectory require a sensor shield to build and run "out of the box".  This is because the default configuration builds all six sensor fusion algorithms, including 9-axis accel/mag/gyro.  The gyro isn't available on the K22F, so the project will hang.  You saw an "error" in I2C address because the 8700 on the K22F is at a different address than the one on the shield boards.  The address is correct for the shield implementation (yes, we DO test all our standard configurations).

Try this, go into build.h and find:

// normally all enabled: degrees of freedom algorithms to be executed

#define COMPUTE_1DOF_P_BASIC  // 1DOF pressure (altitude) and temperature: (pressure)

#define COMPUTE_3DOF_G_BASIC  // 3DOF accel tilt: (accel)

#define COMPUTE_3DOF_B_BASIC  // 3DOF mag eCompass (vehicle): (mag)

#define COMPUTE_3DOF_Y_BASIC  // 3DOF gyro integration: (gyro)

#define COMPUTE_6DOF_GB_BASIC  // 6DOF accel and mag eCompass: (accel + mag)

#define COMPUTE_6DOF_GY_KALMAN  // 6DOF accel and gyro (Kalman): (accel + gyro)

#define COMPUTE_9DOF_GBY_KALMAN  // 9DOF accel, mag and gyro (Kalman): (accel + mag + gyro)

and change them to:

// normally all enabled: degrees of freedom algorithms to be executed

//#define COMPUTE_1DOF_P_BASIC  // 1DOF pressure (altitude) and temperature: (pressure)

#define COMPUTE_3DOF_G_BASIC  // 3DOF accel tilt: (accel)

#define COMPUTE_3DOF_B_BASIC  // 3DOF mag eCompass (vehicle): (mag)

//#define COMPUTE_3DOF_Y_BASIC  // 3DOF gyro integration: (gyro)

#define COMPUTE_6DOF_GB_BASIC  // 6DOF accel and mag eCompass: (accel + mag)

//#define COMPUTE_6DOF_GY_KALMAN  // 6DOF accel and gyro (Kalman): (accel + gyro)

//#define COMPUTE_9DOF_GBY_KALMAN  // 9DOF accel, mag and gyro (Kalman): (accel + mag + gyro)

That will disable all gyro and altimeter related build options.

Regards,

Mike

0 Kudos