Community
cancel
Showing results for 
Search instead for 
Did you mean: 
NSchm2
Novice
2,569 Views

I2C MCU SDK Problems

Dear all,

I am communicating using the mcu sdk over i2c-6. I am transferring data constantly but the transmission stops after a while.

I need to reboot to reactivate the communication. The behavior is reproducible and I would like to know if I can get more information about the communication between I2C <-> Quark <-> CPU.

Several questions:

1. Are the sources of the intel_mcu.a somewhere available ?

2. Can I add aditional functionality to the mcu sdk myself ?

3. Is there a known problem with i2c communication ?

Thanks a lot for any help. It is urgent.

16 Replies
Sergio_A_Intel
Employee
191 Views

Hi,

  1. The sources of intel_mcu.a are not available. That file is found on edison-mcusdk-win64-1.0.10\src\mcu_fw.zip however, it is already compiled and not available for customization.
  2. What do you mean specifically with add additional functionality, what additional features do you need on the SDK?
  3. Using the MCU SDK, there's not any issues reported dealing with I2C. Do you see any error message when the communication stops? Take a look at https://software.intel.com/en-us/node/557354# Getting_debug_messages_from_the_MCU Using the MCU SDK and API: Code examples | Intel® Developer Zone and let us know what errors you receive. Also, take a look at https://software.intel.com/en-us/node/557355 MCU API | Intel® Developer Zone you may find it helpful.

What board are you using the Arduino expansion board or the mini breakout board, what image are you using?

Sergio

NSchm2
Novice
191 Views

Hi,

thanks for the quick reply.

> What do you mean specifically with add additional functionality, what additional features do you need on the SDK?

You provided an API for I2C with a write command "int i2c_write(int address, int reg, unsigned char *buf, int length)". Some I2C devices do not require an address like the PCA9501. If I now specify i2c_write(, , 0, 0) it does not write anything and if I specify i2c_write(, , , 1) I am sending two bytes (address plus the one byte of the buffer).

But to be honest I can also live with the current state.

> Using the MCU SDK, there's not any issues reported dealing with I2C

I can post a minimal code example if it helps. I am using the mcu_sdk intensively and I get an error on the debug /dev/ttymcu1

(263669000,ERROR): I2C READ(0x00000068, 0x0000003a) failed, -1

I am using the Intel Edison with the Mini Breakout board. I have tested the Yocto Image 2.1 and 2.0. It happens on both systems. The minimal (cleaned) code snippet is this

# include "mcu_api.h"

# include "mcu_errno.h"

int my_irq(int req)

{

unsigned char data[21];

int err = i2c_read(0x68, 0x3a, data, 21);

host_send(data, 21);

return IRQ_HANDLED;

}

void mcu_main()

{

int err = gpio_register_interrupt(13, 0, my_irq);

// configuring sensor here ... some i2c_write calls

while (1)

// possibilities to start and stop transmission are here

mcu_sleep(1); // tick = 10ms

}

}

1. Is it for example possible that the quark does not continue if there is a missing i2c transition ?

2. Is is allowed to call host_send inside an interrupt ?

3. Does the quark allow some guard to prevent an interrupt being called twice or is this not possible at all ?

Thanks a lot

NSchm2
Novice
191 Views

Hi,

I just wanted to post a possibility.

Is it possible that i2c_read cannot be called within a interrupt routine since it sends a debug message which is not "interrupt save" ?

If I move the read out of the interrupt the data transmission continues even after a read failure.

Can anyone confirm this ?

Sergio_A_Intel
Employee
191 Views

We're working on your case. We'll post a reply soon.

Sergio

idata
Community Manager
191 Views

Hi,

 

 

Please take a look at our answers below:

 

 

1. Is it for example possible that the quark does not continue if there is a missing i2c transition?

 

The i2c communication resumed normally after disconnecting the i2c sensor. Are you experiencing any issues with missing i2c segments? Can you provide us with more information to reproduce?

 

 

2. Is it allowed to call host_send inside an interrupt?

 

It is possible to call host_send inside an interrupt, as long as the function host_send is used with the proper parameters.

 

 

3. Does the quark allow some guard to prevent an interrupt being called twice or is this not possible at all?

 

A second interrupt will wait until the first interrupt completes execution, then the second interrupt will be executed.

 

 

Sergio

 

NSchm2
Novice
191 Views

Dear Sergio,

first of all thanks for the clarifications.

> The i2c communication resumed normally after disconnecting the i2c sensor.

If the mcu program stops it does not react any more at all. No communication over /dev/ttymcu0 nor /dev/ttymcu1. Also I cannot restart the i2c transmission. I have to reboot the edison. I just got the idea to toggle e gpio continously to see if the mca program at all is still running or not.

 

 

> Are you experiencing any issues with missing i2c segments?

I did not observe missing segments on the oscilloscope. But that might be the case.

 

 

> Can you provide us with more information to reproduce?

At the moment it was just a guess -- or a question. It came to my mind concerning the clock stretching. If a i2c client does clock stretching forever will that stop the mcu program also ?

 

> It is possible to call host_send inside an interrupt, as long as the function host_send is used with the proper parameters.

Perfect. That is good. Is this also true for a debug message with debug_print () ? The i2c_read for example prints something on the dubug output. Assume that there is one debug_print in the main and one in the interrupt. Is that also save ?

 

> A second interrupt will wait until the first interrupt completes execution, then the second interrupt will be executed.

That is also great. How many interrupts can be stored that way. Assume the first interrupt takes one second to process and meanwhile there are 1000 more interrupts. Is it then called also 1000 times ?

 

We still have the problem mentioned above and could not find a solution yet. We are debugging as far as we can but we have no idea what the state of the mcu program is since it does not respond over the two channels /dev/ttymcu{0,1} any more. Is there any way to debug the mcu further ?

 

Yours

Norbert

 

 

NSchm2
Novice
191 Views

Dear all,

I narrowed the problem down. If I use this snippet

unsigned char interrupt_available = 0;

int do_it ( )

{

I2C_READ_N_C ( IMU_ADR, 0x3a, DATA_SIZE );

if ( err ) debug_print(DBG_INFO, "error on data read for %d\n", adr[adr_index]);

if ( err ) return -1;

return 0;

}

int my_irq ( int req )

{

interrupt_available = 1;

return IRQ_HANDLED;

}

void mcu_main()

{

/* your loop code starts here */

while ( 1 )

{

if ( interrupt_available )

{

int error_do_it = do_it();

if (error_do_it)

debug_print (DBG_INFO, "error do_it failed\n");

if (!error_do_it)

interrupt_available = 0;

}

mcu_sleep ( 1 ); // tick = 10ms

unsigned long time = time_us();

if ( diff ( time, wakedog_time ) > (30 * 1000 * 1000) ) // 1s

{

wakedog_time = time;

debug_print (DBG_INFO, "wakedog %d\n", wakedog_count++);

}

}

}

I get the following output:

( INFO): wakedog 40

( INFO): wakedog 41

( INFO): wakedog 42

( INFO): wakedog 43

( INFO): wakedog 44

( INFO): wakedog 45

( INFO): wakedog 46

( INFO): wakedog 47

( INFO): wakedog 48

( INFO): wakedog 49

( INFO): wakedog 50

( INFO): wakedog 51

(3306080408,ERROR): I2C READ(0x00000068, 0x0000003a) failed, -1

( INFO): read size 21 failed adr 104 reg 58

( INFO): error on data read for 26

( INFO): error do_it failed

So the program on the mcu stops working since I do not get any wakedog messages any more after the i2c read error.

Is there anything I can do to analyze that further ? Can someone help me ?

For me it seems as if an error in the i2cread may crash the whole mcu program. Is that right ?

Yours

Norbert

NSchm2
Novice
191 Views

Hi,

the problem still remains. It can be observed under Yocto 2.0, Yocto 2.1. My mcu program is not working under Yocto 3.0 at all. i2C_read stops there which is reported in another thread.

But I need a solution.

Can someone help me how to do debugging on the mcu. The following question are relevant:

1. What happens if a program on the mcu has a segfault ?

2. How can I detect where a mcu program has a segfault ?

3. Is there a way to debug on the mcu ? (Memory layout, program backtrace, ...)

4. Can I get more advanced acces to the MCU to develop further ? (Share mem with CPU, i2c Communication with one byte, spi communiaction, ... )

If I cannot find a solution I have to change the architecture.

idata
Community Manager
191 Views

Hi nagilo,

 

 

We wanted to let you know we're still investigating. We'll post a reply soon.

 

 

Sergio

 

NSchm2
Novice
191 Views

Hi,

thanks a lot -- for me the edison is ideal but I really need the mcu to work.

Also it would be a pleasure to help -- I can spent time on it if you are willing to share information.

Yours

Norbert

idata
Community Manager
191 Views

Hi nagilo,

 

 

As of yet, there are no plans to make any updates to the MCU. The current SDK is the one that will continue to be used. As for your questions in your last reply we're still investigating and we'll post a reply for you as soon as we have an answer.

 

 

Thank you for your patience.

 

 

Sergio
NSchm2
Novice
191 Views

Hi,

thanks for the reply. As you can read in several topics in this forum intel has stated already that access to the mcu will not be opened.

Nevertheless there are reproducible bugs (or features ;-) ) which prevent the platform for being used for serious applications.

I also understand that Intel is not going to share information in a public form but there are other possibilities.

Please consider my serious offer to help.

Yours

Norbert

idata
Community Manager
191 Views

Thank you for offering to help. We've communicated your offer to the engineering team. If anything changes with the Edison's MCU roadmap you offer to help may be considered.

 

 

Best regards,

 

Sergio

 

NSchm2
Novice
191 Views

Hi,

do you have some news meanwhile ?

Yours

Norbert

idata
Community Manager
191 Views

Hi nagilo,

 

 

We don't have any updates as of yet. We'll post here when an update is available.

 

 

-Sergio

 

RBulh
New Contributor I
191 Views

You provided an API for I2C with a write command "int i2c_write(int address, int reg, unsigned char *buf, int length)". Some I2C devices do not require an address like the PCA9501. If I now specify i2c_write(, , 0, 0) it does not write anything and if I specifyi2c_write(, , , 1) I am sending two bytes (address plus the one byte of the buffer).

But to be honest I can also live with the current state.

- For me this is a very important feature. My sensor, TLV493D, needs to be read always from addres 0x00, so I don't need to write the address of the register first. I really need this feature to improve the comunication time and achieve the best sample rate of the sensor.

Reply