We have developed a smart device application on Visual Studio for Win CE 7 Colibri iMX7 Platform that utilizes Rpmsg library( Toradex Library version 2.1) for loading FreeRTOs Demo application( blinking_imx_demo ) to cortex M4 core.
We are unable to locate Rpmsg registry in Win CE so we used Null for registry path in Rpmsg_Init() function, however we didn’t get Handle for Rpmsg communication channel when Rpmsg_Init() executed with NULL registry path.
Also we are not very clear about Firmware and ChannelName in Rpmsg configuration settings.
I have tested Rpmsg_demo release build with demo firmware(sorry, it is missed in our release), it is working. Could you please first test our Rpmsg_Demo with demo firmware, if it is working then proceed to test your firmware and let us know your feedback.
Thanks for this update.
We are now able to move one step further(Rpmsg_Open returned True successfully).
We have first ported this Rpmsg_demo code for Toradex CE 700( as it was configured for Toradex CE 600) and then start debugging on device.
While debugging it throws error on Rpmsg_GetConfigString(hRpmsg, L"ChannelName", channelName, sizeof(channelName));. See Snapshot below:
Thank you for the issue details. I am able to reproduce the problem with your application in Debug configuration. I am working on this. Could you please wait for few days?
The same application successfully runs on Release configuration. Could you please try that?
We have used your preliminary release and able to debug and deploy Rpmsg_demo code. Rpmsg_demo code worked well in release mode, Debug mode still has some issues.
We tried to deploy another cortex M4 code[ blinking_imx_demo from freertos-colibri-imx7 library] from this Rpmsg_demo( by making slight modifications). But in both debug and release mode Rpmsg_demo got hanged, and we need to reboot the system to rectify the issue. And while debugging it hanged while executing Rpmsg_Open() function. It never returned from this point.
Could you please share more information about the issues you are facing?
Debug mode still has some issues.
What is the issue you are facing in the debug mode? Rpmsg_demo debug mode is working for us.
We tried to deploy another cortex M4
code[ blinking_imx_demo from
freertos-colibri-imx7 library] from
this Rpmsg_demo( by making slight
modifications). But in both debug and
release mode Rpmsg_demo got hanged,
and we need to reboot the system to
rectify the issue. And while debugging
it hanged while executing Rpmsg_Open()
function. It never returned from this
Please share your all the modification details. If possible, could you please try the LED blink application with Linux running on A7 processor andl let us know your feedback.
We were working on some other high priority tasks and now come back again to this task, that’s why coming again to this thread.
I am currently using toradexcelibraries_2.3b4555-20190107 library and tested the rpmsg demo application with pingpong example on M4 core. It is running successfully.
Then I tried the other freeRTOS( freertos-colibri-imx7\examples\imx7_colibri_m4\driver_examples ) example applications like ‘gpio_imx’ and ‘uart_imx’ but unable to get the output. Nothing observed on Debug UART also.
I am using Kinetis design studio to build these freertos example codes.
I have also tried modifying the ‘gpio_imx’ application, in that just toggling the level of GPIO in output mode but didn’t get the result.
We are running Win CE 7 on A7 core and currently not in a state to migrate on Linux.
Please guide us to move forward to develop/test application on M4 core.
Thanks for your response.
I have followed the steps provided in the link you have shared in your response but got the error while running build_all.bat file.[ Please see attached image for the error description
I have then tried to build the source code using cmake UI 3.13.3:
Follow the steps:
-select the source folder
-select the destination folder
-configuration - select the “MinGW makefiles” as project generator and then specify tool chain for cross compiling “C:/MinGW/bin/bin/arm-none-eabi-gcc.exe”
-then build the code but it is showing error in configuration [ Please see attached image for the error description ]
I am trying to find out the version of CMake you have mentioned but it is not available on the official website.
It will be helpful if you can share any link to download this version of CMake.
Meanwhile, one more thing I require from you. Please share the output *.elf file you have build gpio_imx and blinking_imx_demo using your Cmake so that I can compare it with my build output from Kinetics design studio.
I have found the cmake version and now able to build freeRtos example codes using cmake & MinGW successfully.
One observation in build output of cmake and Kinetis design studio is that difference in output *.elf file size. I have build “gpio_imx” project using both. With cmake file size is 141KB while output file size of KDS is 2400KB.
As we need to set up development environment for Cortex M4 side application, we are trying to find out the reason as to why there is a build output difference between cmake and KDS. It will be helpful if you can point out some possible reasons of this difference.
The .elf file has a number of optional contents. Most probably your large (2.4MB) file contains debug information. You can either configure your environment to not include debug information, or use a separate tool to strip away debug information from your existing .elf file.
I have tried the link-time optimizer(-flto) and file size reduced drastically. It comes down to 97KB. But i don’t know the effect of this optimization. Can you please explain the effect of this option on the performance of the build.
Also the build output size(text+data+bss) remains same even if this optimization flag is enabled or not and it is only around 11 KB that is much lesser then .elf file size.
We had built the code in KDS and boot it on cortex M4 successfully.
One more thing to ask, Is it possible to use *.hex file instead of *.elf file using rpmsg library to boot firmware on cortex M4 core in imx7D ?
There is a tool FROMELF.exe from ARM, DS-5, Could you use that tool to remove the debug message from .ELF file that will make size reduction and also try to explore various options available in the tool to strip down your firmware size.
As a general rule of compiler optimization setting for the code, as you know the optimized instructions would give better performance as a side effect of some bugs would occur due to race conditions e.g. variables sharing between multiple threads and some peripherals might show different behavior due to reduced time of peripheral configuration instruction execute sequences.
We suggest you develop the firmware with least optimization technique during development stage later on you can set full optimization and do the complete testing and release it for production.
Please let us know if you have any other questions.
I have gone through the CMakeLists.text file of “gpio_imx” project and found that -flto is not used in building the project. I want to know that which option is contributing for such a less output(*.elf) file size while building the project using cmake. File size comes out to be 149KB using cmake.