0

We are using the Atmel SAM4S2C 32 bit ARM microprocessor along with a smart battery, controlled by a bq20z45 controller in it. The Battery sends a message to a (non-present) smart battery charger on the SMBus. It seems that within 24 - 72 hrs the microcontroller and the smart battery try to send data on the bus at the same time. This would usually not be such a huge problem, but sometimes after that incident the SAM4S pulls both TWI-Lines (SDA, SCL) low. We are resetting the bus to overcome this problem, but it would be great to understand what happens here.

We can reproduce this problem by putting a function generator on the bus with a 100kHz square signal. The ARBLST (Arbitration Lost) flag is set in the microprocessor, both lines get pulled low.

Using a bus with the battery disconnected (+ function generator connected) works, too, but tends to be more robust. This might be due to the fact that there is no actual communication with the battery and only the address byte is on the bus. So there is much less communication to collide with.

Has anyone had any problems related to this, too? Any Experience? Reading datasheets over and over again did not bring up any useful results.

The SAM4S is in Master Mode.

Merlin Steuer
  • 1
  • 1
  • Are you sure the SAM4S is pulling them low and not the battery? I wasn't entirely clear on what the result was with the battery disconnected. – rjp Aug 02 '16 at 21:11
  • We pull out the battery when the error occurs. The lines stay low - so I think it is quite sure the SAM4S2C pulls them low. – Merlin Steuer Aug 03 '16 at 09:59

1 Answers1

0

That's how I see this:
SAM4S2C is the master, it sends a start signal + address and at some point during this phase the line is LOW instead of the expected HIGH. This means arbitration lost, just like if is there is another master on the line. Multimaster mode is allowed in some systems. Let's call this virtual second master Virtual-Master.
At this point SAM4S2C is no longer the master, it wants to tell you that it has lost the arbitration hence the ARBLST flag.
Now that Virtual-Master is master, the SAM4S2C is acting like a slave. The slave is allowed to do what is called clock-stretching, which is holding the clock line LOW for as long as it wants, and it will do so for you to have time to do processing before resuming. Now you need to stop the clock stretching in the firmware, I don't remember how, sorry. Then maybe retry the same transfer a few times before showing an error.

wire67
  • 81
  • 7
  • As per datasheet, the SAM4S2C does not go into the slave mode automatically when ARBLST is set. Since we do not enter slave mode manually on this event, this is not the case. Additionally, the registers in the I/O-View of Atmel Studio are in the "Master Mode" state. – Merlin Steuer Aug 03 '16 at 10:00
  • As per official I²C Specification: "The losing master must therefore switch over immediately to its slave mode." Is seems acceptable that the SAM4S2C doesn't change its configuration itself as this is only a temporary state. Source: http://www.nxp.com/documents/user_manual/UM10204.pdf – wire67 Aug 04 '16 at 13:21