If you have recently purchased an AGM01 kit, you may have noticed that it comes with projects that were made for CW 10.6 and KDS 1.1.1. The latest recommended IDE for Kinetis parts is KDS 3.0 with an optional KSDK. Until the download on the webpage is updated, you must do a few things to get up and running in KDS 3.0. This guide is for people who just want to use the sensor library without having to dig into the KDS documentation.
In KDS
1. Go to File > Import > Existing Projects > Browse > {directory_where_you_extracted_the_sensor_ fusion_library} > {Project}. Ex. FSFK_K64F
2. When you first import a project, a dialog pops up asking if you would like to load a newer component version for MQXLITE, I clicked Yes to All.
If you try to clean and build the project at this stage, you get an .elf error as the linker can't find nanolibc, even though the Libary search path is set correctly "${ProjDirPath}/Project_Settings/Linker_Files".
3. Right click on the project > Properties > C/C++ Build > Settings > Cross ARM C++ Linker > Miscellaneous > Other linker flags = -specs=nano.specs -specs=nosys.specs.
After that the project compiles with a few warnings and you can setup a debug configuration by right clicking on the project > Debug as > Right click on debugger type > New and it should auto-fill the project and C/C++ application, but be sure to specify the right device in the "debugger" tab.
Then hit the Debug and you're away!
I'm glad this posts exists because there isn't much information listed about this the K64F and AGM01 combo. Unfortunately I am encountering a few issues with KDS 3.0.0 with KSDK 1.3.0 and Sensor Fusion Library Build 421. I am running Windows 7 x64 Enterprise Edition. KDS is up to date as of 12/16/15 using the built in updater. I follow all steps that you listed.
The first issue is that I receive a J-Link V5.10d Warning that states "The connected emulator does not support serial wire output (SWO)." The Sensor Fustion library documentation recommends the Segger solution (https://www.segger.com/opensda.html). I've installed the latest Segger software package, Windows V5.10d, along with the latest bootloader, JLink_OpenSDA_V2_2015-10-13.
My debugging configuration is the default setup matching the screenshot you provided.
I acknowledge the warning and continue to debug. Should I be encountering this error?
Secondly, what Processor Expert components must be changed to support the FRDM-K64F_AGM01 configuration? The default settings result in the code getting stuck at a while loop in the FXOS8700_Init function. The FRDM-STBC_AGM01 jumpers are set to the default location. Based on your post, it sounds like it should just work as is.
I have no problem using the Freescale Sensor Fusion Toolbox with the correct bin file and bootloader.
Thanks
Jeremiah,
The 4.22 library was published well before the AGM01 board was a gleam in our app's manager's eyes. It was also before the introduction of KDS3.0. I HIGHLY suggest you go ahead and upgrade to the 5.00 library. The latest set of canned projects has everything you'll need to get up and running quickly. Starting with the FSFK_K64F project, open up build.h and make the following changes:
then re-generate code using Processor Expert and rebuild. That should be all it takes.
I'm not a lot of help on the KDS debugging problem, as I'm not an expert there. I'm currently using the MBED bootloader and simply doing a drag and drop of the generated binary to install it on the board. I would suggest cross-posting to the KDS community on that topic.
Mike
Mike,
The 5.0.0 library did fix my major issue. However, I had to uncomment line 96 (#define USE_MPL3115). With it commented out, the build process failed due to undefined reference to 'thisPressure'.
'Building target: FSFK_K64F.elf'
'Invoking: Cross ARM C++ Linker'
arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -O3 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -Wall -g -T "C:/Users/gillije/workspace.kds/FSFK_K64F/Project_Settings/Linker_Files/ProcessorExpert.ld" -Xlinker --gc-sections -L"C:/Users/gillije/workspace.kds/FSFK_K64F/Project_Settings/Linker_Files" -Wl,-Map,"FSFK_K64F.map" -specs=nano.specs -specs=nosys.specs -o "FSFK_K64F.elf" ./Static_Code/System/CPU_Init.o ./Static_Code/System/Peripherals_Init.o ./Static_Code/System/Vectors.o ./Sources/Events.o ./Sources/approximations.o ./Sources/drivers.o ./Sources/fusion.o ./Sources/magnetic.o ./Sources/main.o ./Sources/matrix.o ./Sources/mqx_tasks.o ./Sources/orientation.o ./Sources/user_tasks.o ./Project_Settings/Startup_Code/startup.o ./MQXLITE/psp/cortex_m/core/M4/boot.o ./MQXLITE/psp/cortex_m/core/M4/dispatch.o ./MQXLITE/psp/cortex_m/cortex.o ./MQXLITE/psp/cortex_m/int_gkis.o ./MQXLITE/psp/cortex_m/int_inst.o ./MQXLITE/psp/cortex_m/int_kisr.o ./MQXLITE/psp/cortex_m/int_pvta.o ./MQXLITE/psp/cortex_m/int_unx.o ./MQXLITE/psp/cortex_m/int_vtab.o ./MQXLITE/psp/cortex_m/int_xcpt.o ./MQXLITE/psp/cortex_m/mem_zero.o ./MQXLITE/psp/cortex_m/psp_iinit.o ./MQXLITE/psp/cortex_m/psp_supp.o ./MQXLITE/psp/cortex_m/psp_tiad.o ./MQXLITE/psp/cortex_m/psp_tinm.o ./MQXLITE/psp/cortex_m/psp_tipr.o ./MQXLITE/psp/cortex_m/psp_tisu.o ./MQXLITE/psp/cortex_m/sc_irdyq.o ./MQXLITE/psp/cortex_m/stack_bu.o ./MQXLITE/psp/cortex_m/stack_de.o ./MQXLITE/psp/cortex_m/stack_st.o ./MQXLITE/kernel/idletask.o ./MQXLITE/kernel/int.o ./MQXLITE/kernel/klog.o ./MQXLITE/kernel/lwevent.o ./MQXLITE/kernel/lwlog.o ./MQXLITE/kernel/lwmem.o ./MQXLITE/kernel/lwmsgq.o ./MQXLITE/kernel/lwsem.o ./MQXLITE/kernel/lwtimer.o ./MQXLITE/kernel/mqx_utils.o ./MQXLITE/kernel/mqxlite.o ./MQXLITE/kernel/mutex.o ./MQXLITE/kernel/qu_test.o ./MQXLITE/kernel/sched.o ./MQXLITE/kernel/task.o ./MQXLITE/kernel/time_ticks.o ./MQXLITE/config/task_template_list.o ./Generated_Code/Cpu.o ./Generated_Code/FTM.o ./Generated_Code/I2C.o ./Generated_Code/LED_GREEN.o ./Generated_Code/LED_RED.o ./Generated_Code/MQX1.o ./Generated_Code/PE_LDD.o ./Generated_Code/SystemTimer1.o ./Generated_Code/UART_A.o ./Generated_Code/UART_B.o
./Sources/drivers.o: In function `CreateAndSendPacketsViaUART':
C:\Users\gillije\workspace.kds\FSFK_K64F\FLASH/../Sources/drivers.c:1358: undefined reference to `thisPressure'
./Sources/mqx_tasks.o: In function `Fusion_task':
C:\Users\gillije\workspace.kds\FSFK_K64F\FLASH/../Sources/mqx_tasks.c:429: undefined reference to `thisPressure'
collect2.exe: error: ld returned 1 exit status
make: *** [FSFK_K64F.elf] Error 1
I am able to run the program, debug, and use the Freescale Sensor Fusion Toolbox with USE_MPL3115 left in.
I still receive the J-Link V5.10d Warning. I don't mind it for now since I can continue development.
Regards,
Jeremiah
Jerimiah,
Thanks for the update. I'll have to chase down that extra reference to thisPressure. Sounds like we missed inserting a conditional compile option.
Mike
About that missing link, thanks for pointing it out. It got broken in the cross over to NXP last week. We just spotted it this morning and have requested a fix. Thanks. I'm glad you found the preview version.
Mike,
Thanks for the prompt reply. I will proceed with your steps. Unfortunately on the Sensor Fusion|NXP page, the Sensor Fusion Library for Kinetis MCUs 5.0 link results in a Page Not Found (404). The Sensor Fusion Toolbox for Windows link on the same page works. Can your provide an alternative download link until it is fixed?
Edit - I found an alternative link at Freescale Sensor Fusion Revision 5 Early Release
Thanks,
Jeremiah
Reviving this thread, because I'm unable to build the sample project.
I have a FRDM-K64F-AGM01 and KDS 3.0.0 (I'm on Mac, but it doesn't build on Windows either)
I imported the FSFK-K64F project, accepted the prompt to upgrade MQXLite, and selected "Use newlib-nano" in the project properties.
I also imported ksdk_platform_lib_K64F12, because the other demos need it. But I'm completely new to KDS so I might not know what I'm doing.
When I build I get an obscure makefile error:
Static_Code/System/subdir.mk:23: *** target pattern contains no `%'. Stop.
Line 23 is the rule to build CPU_init.o. It has a path that doesn't make sense; it refers to "C:/Freescale/KDS_1.1.1" which does not exist within KDS_3.0.0.app.
# Each subdirectory must supply rules for building sources it contributes
Static_Code/System/CPU_Init.o: /Applications/KDS_3.0.0.app/Contents/eclipse/C:/Freescale/KDS_1.1.1/eclipse/ProcessorExpert/lib/Kinetis/pdd2/MK64FN1M0LL12/system/CPU_Init.c
@echo 'Building file: $<'
@echo 'Invoking: Cross ARM C Compiler'
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -O3 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -Wall -g -DK64F -I"/Applications/KDS_3.0.0.app/Contents/eclipse/ProcessorExpert/lib/Kinetis/pdd/inc" -I"/Applications/KDS_3.0.0.app/Contents/eclipse/ProcessorExpert/lib/Kinetis/iofiles" -I"/code/FreescaleSensorFusion/Sensor Fusion Library/KDS/FSFK_K64F/Sources" -I"/code/FreescaleSensorFusion/Sensor Fusion Library/KDS/FSFK_K64F/Generated_Code" -I"/code/FreescaleSensorFusion/Sensor Fusion Library/KDS/FSFK_K64F/MQXLITE/include" -I"/code/FreescaleSensorFusion/Sensor Fusion Library/KDS/FSFK_K64F/MQXLITE/config" -I"/code/FreescaleSensorFusion/Sensor Fusion Library/KDS/FSFK_K64F/MQXLITE/kernel" -I"/code/FreescaleSensorFusion/Sensor Fusion Library/KDS/FSFK_K64F/MQXLITE/psp/cortex_m" -I"/code/FreescaleSensorFusion/Sensor Fusion Library/KDS/FSFK_K64F/MQXLITE/psp/cortex_m/core/M4" -I"/code/FreescaleSensorFusion/Sensor Fusion Library/KDS/FSFK_K64F/MQXLITE/psp/cortex_m/compiler/cwgcc" -I"/Applications/KDS_3.0.0.app/Contents/eclipse/ProcessorExpert/lib/Kinetis/pdd2/MK64FN1M0LL12/system" -I"/Applications/KDS_3.0.0.app/Contents/eclipse/ProcessorExpert/lib/Kinetis/pdd2/MK64FN1M0LL12/peripherals" -std=c99 -MMD -MP -MF"Static_Code/System/CPU_Init.d" -MT"Static_Code/System/CPU_Init.d" -c -o "$@" "$<"
@echo 'Finished building: $<'
@echo ' '
Thanks!
Sean
Ahh, I was able to reproduce your error because I had previously been working on a project that wasn't using processor expert, and it references that path that makes no sense as you said.
You need to double click the ProcessorExpert.pe (XML) file which causes eclipse to switch to a different context with special processor expert windows such as the component inspector in the screenshot. Most importantly that path error is now gone.
mcuoneclipse is a great resource for using processor expert. Also, I think it's worth mentioning Esquilo here as they have ported a madgwick sensor fusion implementation that uses the AGM01 shield only on their custom K64 board (exact same chip as FRDM-K64F).
lib/README.md at master · esquiloio/lib · GitHub
They claim the madgwick sensor fusion is 1/10th the size and ~98% as accurate as the "mathematically pure" Kalman algorithm provided in the sensor fusion release, but don't quote me on those numbers.
Also for people wanting to get up and running really fast, there is an AGM01 library on mbed.org, and a madgwick sensor fusion port is in progress.
That was super helpful Angus. Thanks!
Yes, I also am evaluating Madgwick and confirm it is very small/fast compared to Kalman filters.
The output of Madgwick is noisy though (it oscillates) and requires a median filter.
For others reading this thread, you can find details on the Madgwick approach at Open source IMU and AHRS algorithms | x-io Technologies .
We (Freescale sensors team) looked at Madgwick when we first started our sensor fusion effort, but never took it past the Matlab stage. I'll be interested to see how well it works out for you. An interesting twist would be to use Freescale's magnetic calibration routines to preprocess the magnetic input to Madgwick (which has simpler assumptions in that area).
Good luck!
Mike
Hey Micheal,
My fellow intern rioshauneharris-b50559 is actually doing just that! She was advised to port the MQX task that does the periodic magnetic calibration to the Madgwick mbed sensor fusion library she's working on. The DIY quad-copter crowd is using MagMaster which is basically a PC application that does a one time calibration, but for other environments it's nice to use the Freescale code that checks the quality of the calibration and then does an update if a better one is received.
Hi Angus,
Thanks for the info above. This works for FRDM-KL25Z brd too but it isn't for the FRDM-KL26Z. I keep getting this error message. Any idea?
Thanks.
Devan
Hey Devan,
You can copy paste that string "-specs=nano.specs -specs=nosys.specs" into the other linker flags box. It builds ok for me, just 2 warnings about an upper I2C limit of 100kHz. I think you made a typo "nanospecs" it should be "nano.specs".
- Angus
Gotcha! Thanks Angus and a good pick up! :smileyhappy:
Silly me and all good now.
Cheers,
Devan
Hi Angus,
I just thought I would let you know this option as this one works as well.You will get the same results without any errors by just ticking the box (Use newlib-nano (--specs=nano.specs)) which is already there in the "other linker flags" box. See below.
Cheers! :smileyhappy: