Hello,
One of my friends at Freescale has gifted me with a FRDM-STBC-AGM01 board, and I was very fond of testing it with the new Freedom Sensor Toolbox. I thought the new Kinetis Interface Tool very interesting, and I have followed all the necessary steps to make it work with the new board and a FRDM-K64F. I have flashed the firmware into the board, and then I managed to establish connection with the tool. I loaded the appropriate command sequence file for the tests, and then I got an error at the "Start APP Streaming" command.
This is what I get at the Command / Response window:
So I thought it could be a bug at the byte command sequence, or a bug at the firmware flashed into the K64. So, I switched the K64F board to a KL25, and I flashed the corresponding firmware. Then, I used the same command sequence file, and it worked! Thus, I believe that there is some bug at the K64 firmware.
If I try to use the original "Sensor Fusion Toolbox" view, the K25 board (and the corresponding firmware) is recognized and I manage to get data from the sensors. The K64 is not working for this view either.
I have tried everything for a second K64 board, with no success. I am using Windows 7.
Any clues about the problem? A firmware bug, or a problem when flashing the K64 board through windows 7?
Cheers,
Antonio
Solved! Go to Solution.
Bruno,
Can you send me your contact information (to mike.stanley@freescale.com) and I'll have someone from the ISF team give you a call?
Thanks,
Mike
Same problem here....
Any solutions? Tested it on two K64F boards, but I always get the same error...
Reference the table below to understand compatibility issues related to windows client versus embedded code.
I'll also note that in Version 4.22 of the Sensor Fusion Library for Kinetis MCUs, we had to (at compile time) specify which UART is to be used for communications. This sometimes caused problems when users didn't realize they needed to make a change depending upon whether or not they were using a wired or a wireless connection to the PC. I suspect that is your problem. Version 5.00 of the library resolved that problem by sending UART traffic to both UARTS.
So your choices are to either recompile for your specific wired/wireless situation (see the user guide) using Version 4.22, or upgrade to Version 5.00 (recommended). The link for the later is at http://www.freescale.com/sensorfusion.
Windows-Based Firmware | Sensor Fusion Capable | Communications Protocol | Embedded Library | Links |
---|---|---|---|---|
Kinetis Interface Tool (AKA KIT) | No | ISF Command Interface | ISF | Find ISF at freescale.com/isf. Also, see Sensors Toolbox below |
Freescale Sensor Fusion Tookit for Windows | YES | Not ISF compatible. Specific to Freescale Sensor Fusion Library for Kinetis | Version 4.22 of the library is deprecated. Version 5.00 is the current version. | freescale.com/sensorfusion |
Sensors Toolbox | The sensors toolbox is a wrapper tool which can call the Kinetis Interface Tool OR the Freescale Sensor Fusion Toolbox | See above | ISF | Sensor Toolbox|Freescale |
Hi Michael.
I was able to run the demos using the Kinetis Interface Tool, downloading each firmware and running commands to start streaming.
The problem is that I can't build a project on Kinetis Design Studio using ISF Components. See, when I try to use a ISFCOre, it automatically add a ISF_CI_Protocol Component, and that adds an error. It seems that the selected processor (I'm using the K64F board) does not support CI procotol (see the image).
The project builds only if I remove this Component, and that, I think, is the cause to receive a device error when I send command to start the data streaming.
I've tried several configurations for the protocol, but it does not work.
It's curious that all the demos (compiled firmwares) run exactly as expected, but if I download a sample project (ISF_K64F_KDS_PROJ for instance) and build it and run it, I get the start streaming error during communication.
Any ideas?
Thank you for your reply.
Bruno,
I've got a couple, and if those don't work for you, I'll pull in some of our ISF experts to help sort things. My projects are Codwarrior-based. It's possible that there might be some differences between the two platforms. I can tell you for a fact that ISF (including the command interface) should work just fine with the K64F, as it is a board I use for a lot of my own projects.
So try deleting the 2 CPUs you have and replacing them with the MK64FN1M0VLL12. Then let us know the result. Please note that today is a holiday for for the US-based ISF team, so further feedback may have to wait until Monday.
Good luck!
Mike
Hello Michael.
I've noticed all those points earlier, but even making the appropriate changes, still makes no difference. :smileysad:
I also noticed that the template project, for ISF, brings the wrong processor, MK64FNM0VLQ12, and duplicate it.
Could the problem be the ISF R2P1 PEx.PEupd file? Is it possible to get the project to build the .PEupd file?
One more thing, I've updated all the plugins, the KSDK, and so on...everything is up to date with the KDS.
Again, thank you for you help.
Wrong image above, here is the right one:
Bruno,
Can you send me your contact information (to mike.stanley@freescale.com) and I'll have someone from the ISF team give you a call?
Thanks,
Mike
Hi Antonio,
I am working to reproduce this issue and see if we can get it resolved, but I have a couple questions:
To start I am concerned there may be a hardware issue with your K64F, it is very strange for both tools to work for the KL25Z and not the K64F
When you say "I loaded the appropriate command sequence file" from the commands it looks like you mean the "Subscription 1 Quick Read Streaming Commands.txt" file. Is this correct?
Your command log ends at "Protocol: ISF Command Interpreter - Device Response Error!" can you please reply with the bytes below that line? It is probably a generic error (9C) but if it is not it may help me reproduce.
Thanks,
Troy
Hello, Troy,
It took me 2 days to answer your questions because I was away from my office, where the devices did not work. Now I have done the procedures again (Board programming and command sequence file) to reproduce the error.
First of all... yes, I am using the "Subscription 1 Quick Read Streaming Commands.txt" file.
Here are the last 3 lines of my previous command log, added with the response from the device:
I hope it helps
Cheers,
Antonio
Hi Antonio,
I have as yet not been able to reproduce the issue here, I have several K64F + AGM01 and they have flashed and streamed data without issue. The 9C error from the Start Streaming command usually means that there is some problem performing initial sensor setup for streaming, but that could be any number of issues...
Could you try using the ISF CI Streaming protocol and see if this experiences the same issue? To do this just program the board with the KIT AGM01 - FRDM_K64F firmware, connect to the board using "Search for ISF Device" and then use the first six commands from the "Command Interpreter Stream Examples.txt" file to start streaming.
Regards,
Troy
Hi Antonio,
Let me give you some historical background on the tools, and let's see if that sheds some light.
There are two different sensor fusion implementations. There is a "standalone version" (most recently released in Nov 2014) which includes its own sensor drivers and makes use of PE LDD communications drivers. The 2nd version is built on top of the ISF (Intelligent Sensing Framework). The underlying fusion code is the same. The precompiled binaries included in the Sensor Fusion Toolbox for Windows were built using the first (non-ISF) version. They do not support the ISF Command Interface, which is what the "Kinetis Interface Tool" (KIT) uses. So the two are incompatible. You can build a sensor fusion application that uses the ISF interfaces and would work with the KIT, but you won't get all the visualizations in the Sensor Fusion Toolbox.
Does that help?
Mike
Hello Michael,
When I call the KIT, there is a "Board Programming" tab, with options for flashing the appropriate communication ISF firmware to several combinations of microcontroller and sensor boards. I tried flashing what the KIT offered for FRDM-K64F + FRDM-STBC-AGM01, and it did not work with the KIT. When I tried using a FRDM-KL25, with the corresponding firmware, it worked OK. When I ran the Toolbox Launcher and selected the "classic" Sensor Fusion Toolbox from it, I got the same software (at least at its GUI) that I was using before: the one with the image of the boards, that rotate following the real board orientation. This also worked fine for the FRDM-KL25 + FRDM-STBC-AGM01 combination, but it did not work with the FRDM-K64F either.
Notice from the KIT messages from my original post that all commands sent through ISF to the K64 board worked, but the one that should start data streaming. Thus, the ISF firmware is working partially. Also, when I stress the possibility of a problem when flashing the board through windows 7, that's because I have had problems when sending binaries to the FRDM-K64F directly from the browser, i.e., using MBED and when compiling, saving the binary directly into the virtual MSD corresponding to the board. Usually when I do that, the board does not work, so I always save the MBED binary file to my workspace, and then I move the file from it to the K64 MSD. Maybe the toolbox is having problems flashing the K64F directly.
Right now, an idea has ocurred to me. I decided to keep the original text above so you can follow my train of thought, but I jave just tested that and the results are interesting. I tried using the toolbox in my office computer, running windows 7. Now I am using my home laptop, with windows 8, and I was lucky to bring home the FRDM-STBC-AGM01 board, to play with ome of my KL25 boards. So I grabbed my "home" K64 board, and tried using both the KIT and the "classic" toolbox. When I tried the KIT (flashing the corresponding firmware), the board started streaming data after the corresponding command, but after a few seconds it froze. When using the "classic" toolbox (and again flashing the suggested firmware), it worked perfectly!
Any clues on that?
Antonio,
I'm glad you have at least one working path. I'm not totally familiar with the Kinetis Interface Tool, so I'll check with its developer tomorrow and ask him to join the discussion.
Regards,
Mike