[SOLVED] SAMD21 I2C Slave Mode Data Write Failure

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, I am working on a project that is using a SAMD21G18A to communicate with an STM32F4 over I2C. The STM32F4 is the Master and the SAMD21 is the Slave. Both are operating and communicating at 3.3v. The communication is running at 100kHz and at the moment the SAMD21 is the only slave on the bus.

 

I am strictly having the Master read 3 bytes from the SAMD21 Slave. The issue I am facing is that some of the messages are getting corrupted in the middle of the slave transmitting one of its 3 bytes. What happens is the slave begins asserting the data bits for that byte, but then on a rising edge of clock the data being asserted is changed to the next bit. Both which byte gets corrupted and which clock edge are random. I have set my 3 bytes to be 0x55 so that SDA will always change state on the falling edge of clock. This is how I can tell that the data being asserted is changed to the next bit.

 

Because the data changes state after the rising edge of the clock, the Master detects this as either a Start or Stop bit and haults the communication do to an error. It then tried to reset the slave I2C state machine by driving a Start bit then Stop bit. This behavior can be seen in the capture below after the issue occurs (circled in red), and is correct behavior.

 

Below you can see a scope capture of the issue (Yellow is SDA,  Blue is SCL):

 

Here is one with the waveforms vertically displaced for clarity:

 

 

I have found that reducing the value of the pull-up resistors makes this issue happen less and less. Using 4.7k the issue occurs about every 3 transactions. Using 1k the issue occurs about every 10 transactions. Using 330 ohm the issue occurs about every 20-25 transactions. I realized after trying the 330 ohm that this may not have been a good idea since the SAMD21 datasheet specifies the I/O Pin maximum low-level current rating as 10mA. Since Vdd is 3.3v, I was right at the limit of the I/O pin. Another thing to note from my investigation into the pull-up influence, is that the pull-up on SCL is what matters. The pull-up on SDA does not affect this issue at all.

 

I am using the example code provided for I2C slave callbacks using ASF 3. I will post my code later, but there are no changes to the ASF example. The project is a clean project with only this example code running. As I understand it, at this point in the transaction, the code should not be interacting with the communication at all and the data should be shifted out at the hardware level inside the SAMD21. I have searched all over for a solution or even a similar issue with no luck. Any help with this would be greatly appreciated. I can post captures of anything that is needed so please just ask if you would like me to provide more scope or logic analyzer captures.

This topic has a solution.
Last Edited: Thu. Aug 30, 2018 - 01:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not familiar with the SAMD21, does it have a TWI hardware or are you bit banging the protocol?

If bit banging, how are you driving the output of the data pin?

 

Jim

 

 

FF = PI > S.E.T

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The SAMD21 has TWI hardware (From datasheet):

I forgot to mention that I am using SERCOM4 and PB08/PB09 for SDA/SCL respectively.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think I found the issue. There is a note at the end of the pin mapping chart that says only some pins are capable of I2C and those are marked by "I2C" in the "Type" column. I did not notice this when choosing my communication pins. I will verify this is the issue by changing the pins used on a dev board.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ricco12 wrote:
only some pins are capable of I2C

Indeed. That is a hardware feature - nothing specifically to do with ASF.

 

I think the thing is that those are the only pins that support open-drain outputs - all the others are push-pull ?

 

EDIT

 

See #10 for Microchip's own explanation

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Sat. Sep 1, 2018 - 12:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ya, I originally had thought that any pin connected to a SERCOM module could be used for all SERCOM functions and missed this note. What surprises me is that the communication works most of the time. I would expect much more blatant issues to occur when using a pin that is not made for the function I am using it for.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ricco12 wrote:
I am using SERCOM4 and PB08/PB09 for SDA/SCL 

From the table posted in #4, it looks like only PA08/PA09 can support I2C - and only on SERCOM 0 or 2

 

sad

 

Ricco12 wrote:
What surprises me is that the communication works most of the time. I would expect much more blatant issues to occur

Indeed.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was able to confirm that the issue goes away completely, even when not using any pull-ups, after changing the SDA/SCL pins to PA16/PA17  respectively and using SERCOM1 or 3.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jolly good!

 

Please mark the solution as described in Tip #5.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Independently, I recently corresponded with MicroChip support about the note that only certain pins support I2C, asking for further details on this. Their response:

 

In practice any pins will work if the bus capacitance is low. So if you are driving only a couple slaves, then you are fine with either set of pins. But if you are connecting a lot of slaves, then you should go with dedicated I2C pins, otherwise you may need to reduce the clock speed a lot.

I2C pins just have higher driving strength. This is absolutely necessary for HS mode, but is also required to fully meet the requirements of the formal I2C specification even in a low speed mode. 

We have created a bug to improve the datasheet clarity on this.
 

On our own boards, we've been using any SERCOM pins, and haven't had trouble. We use fairly weak pullups with I2C (like 10k), and usually don't run I2C above 400kHz, so it appears these differences don't matter so much for everyday I2C use. As they note, the OP was using stronger pull-ups initially. Also we have rarely used I2C slave mode: mostly we are talking to sensors and other external I2C slaves. In the future, we will prefer the pins with higher driving strength.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Ricco12, I'd guess that you didn't have pullups enabled on the STM32F4, so they weren't in parallel with your external pullups, but just want to check that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danhalbert wrote:
Their response:

We have created a bug to improve the datasheet clarity on this.

If you're still in contact with Microchip on this, please would you point them to this post: https://community.atmel.com/comm... and my reply?

 

They have made the presentation of this essential information a lot less clear than it used to be in the old Atmel datasheets (as shown in #4 above).

 

angry

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

danhalbert wrote:

Their response:

 

We have created a bug to improve the datasheet clarity on this.

If you're still in contact with Microchip on this, please would you point them to this post: https://community.atmel.com/comm... and my reply?

 

They have made the presentation of this essential information a lot less clear than it used to be in the old Atmel datasheets (as shown in #4 above).

 

angry

My support case has already been closed, but they did say they opened an issue on this, so I'd hope for a datasheet improvement in the next revision cycle. In the meantime, I know the answer :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh well - I thought you might say that.

 

Microchip wrote:
We have created a bug to improve the datasheet clarity

What they really mean is, "restore the clarity which was there before they messed with it" !

 

angry

 

Their new format is a mess - page breaks in really inappropriate and unhelpful places!

You'd have thought they'd have professional technical authors who would know about this stuff ... ?

 

<rolls eyes>

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...