Issues with time_ms() and time_us() in MCU API when using host_send() and host_receive()

[BMass]

Hello everyone,

In spite of the current limitations of the MCU, I managed to build a proper application using I2C, UART1 and GPIO at quite a high rate (sensors are read on I2C at several hundred times per second)

I have used time_ms() and time_us() for software timers without any issues until now.

But now I am additionnally using the interface with host (host_send() and host_receive()) to exchange information with an application running on Linux and I'm facing a weird issue with the values returned by time_ms() and time_us() functions. It seems that sometimes, around 220 seconds are suddenly added to the execution time.

I am writing the value on /dev/ttymcu1 for debug purpose every 8 second and here is an example of the values retrieved :

248

256

264

272

499 <-- suddenly around 220s more

725 <-- same here

956 <-- same here

964

972

1201 <-- same here

This happens only when data are transferred between the MCU and host on /dev/ttymcu0

Did anyone who use the MCU already have this issue or would have some idea to solve the problem ?

Many thanks in advance,

[Carlos_M_Intel]

Hi Bylos,

Which image version are you using?

Is this only happening on your app with I2C, UART and GPIO features? Or is it also happening without those features?

Could you provide the code you are using to test this?

On linux side, are you just reading with cat /dev/ttymcu1? Or are you doing something else?

Please let us know as much you can about this in order to replicate it.

Regards,

Charlie

[BMass]

Hi Charlie, thank you for your answer,

I have updated the Intel Edison with the following image 2.1 Yocto :

edison-iotdk-image-280915

and the command configure_edison --version returns 159

Also on the linux side, I am reading with 'cat /dev/ttymcu1' and I have an application that reads and writes on '/dev/ttymcu0' for the communication between mcu and host.

Basically this is a C++ application, using fcntl.h/termios.h/ioctl.h to handle the serial port. It sends a small amount of data (around 6 bytes) twice a second to the mcu.

I have removed as many things as possible from the application (I2C, UART, GPIO, and so on) and this also happens without those features.

Actually this happens only when the function 'host_receive()' returns something different than 0 and effectively reads data

Below is a simple example where this happens:

# include "mcu_api.h"

# include "mcu_errno.h"

void mcu_main() {

unsigned long time_now, time_old = 0;

unsigned char buffer[256];

int n, count = 0;

while(1) {

time_now = time_ms();

n = host_receive(buffer, 256);

if (n > 0) count ++;

if (time_now - time_old > 1000) {

debug_print(DBG_INFO, "time: %d; count: %d\n", time_now/1000, count);

time_old = time_now;

count = 0;

}

}

}

While there is nothing on /dev/ttymcu0 everything is fine, but as soon as I do write with the application, or even with a simple echo lalala > /dev/ttymcu0 this happens

I hope that this info can help,

Regards

EDIT: Actually this happens even if the data are not read with 'host_receive()'

Just writing something to /dev/ttymcu0' makes the execution time jump over exactly 224 seconds

[Carlos_M_Intel]

Hi Bylos,

Thanks for sharing the code you are using. I tested and I'm having the same behavior.

I'm using the 159.devkit version on my Edison and your code.

Once the code is running I'm able to see the output with time and the value and it works fine.

When I use cat /dev/ttymcu0 and close the reading to send a value with echo lalala > /dev/ttymcu0 I have the offset of 224 just like you.

Let me do some research and more tests in order to check if there is something we could try for avoiding this behavior.

Kind regards,

Carlos

[BMass]

Hi CMata_Intel,

I'm glad that the issue does not happen on my board.

Thank you very much for the tests, please feel free to let me know if I could do anything to help !

[TVin1]

I have found that this behavior also occurs when interrupts are triggered.

[BMass]

Hi CMata_Intel,

Any hope for a workaround/bugfix ? We are currently estimating the execution time of every functions in our program to implement a manual time counter.

This may keep a execution rate pretty closed to the previous fixed rate using time_ms() but we think this is not long-lasting solution.

Any feedback will be appreciated !

Regards,

[Carlos_M_Intel]

Hi Bylos,

Unfortunately we don't have updates yet, we are still working on this and we will notify you when we get some news

Regards,

Charlie