Few more behaviors we observed regarding the above problem are:
1. MCU stops responding after sending specific number of messages like in our application it stops after 2805 continuous messages.
2. It needs reboot to resume the application.
3. if we stop the application in running state and then resume, then also when the number of messages from MCU to Host cross 2805, MCU stops responding.
The API used in our application, to interact with MCU are:
//To open the MCU
*handle = open("/dev/ttymcu0", O_RDWR | O_NOCTTY | O_NONBLOCK);
//To send messages from MCU to Host
Is there any message queue maintained in MCU, which is being overflowed and needs to be cleared from Host? if yes then which are the APIs to manage/flush this message queue? Or is there any other mechanism to get the continuous messages from MCU to Host without any MCU freeze?
Appreciate your inputs and pointers for these questions.
This message was posted on behalf of Intel Corporation1 of 1 people found this helpful
I tried to do the communication on my Edison between the Host and the MCU, I copied the example code of the API (https://software.intel.com/en-us/node/557354#Communicating_between_the_host_and_the_MCU) and I did some changes like, send the message every 200ms and the message is a counter to see the number of the message.
I ran the code on the terminal of the Edison and it didn't stop (still running at message 6000, Aprox: 20 minutes). So can you please provide me your code to test it to help you? You can also try to run the example code and see if you get the error too.
I hope you find the example useful and I will be waiting for your answer to help you.
2 of 2 people found this helpful
I had the same problem.
The problem was caused by the secondary MCU serial line, used as a debug output.
The sample code here: Using the MCU SDK and API: Code examples | Intel® Software / Communicating between the host and the MCU worked fine,
but after a definite time period the Edison went unresponsive. It took some time to find, that the following line:
debug_print(DBG_INFO, "received start command!\n");
overloaded the host cpu buffer, in lack of any receiver progrem to empty the buffer on the host side.
Remove this line, and the lockup should disappear.
More detailed explanation here:
Check post 8.
1 of 1 people found this helpful
Thank you Leonardo and Istvan for your help!!
We upgraded the firmware to the latest version and also removed the debug logs in the MCU code.
After this we didn't observe the issue.