Go Down

Topic: Shield TwoWire SDA and SCL connections stop Crypto Initialization (Read 576 times) previous topic - next topic


So, I have a MKR1000 sitting on a MKR2UNO with a Make Motor Shield sitting on the MKR2UNO and when the Motor Shield is connected, the MKR1000 will not completely boot and does not login to the IoT Cloud.    After some debug, I found it was getting stuck at  ECCX08Class::begin() 'wakeup' from the ECCX08.cpp file.   Without the Motor Shield connected, the board works fine.   

I do have another Sketch where I can use the Motor Shield on the MKR2UNO with the MKR1000 standalone without the IoT Cloud connect.  However, when I load the code from the Create Editor for the Thing I created in IoT Cloud, the board will not boot.  To get past this, I have extended Arduino Headers on the Motor board and move the SDA and SCL pins (D11 and D12 on the MKR2UNO and pins 6 and 7 on the MKR1000) so they do not connect to the MKR2UNO board, and thus the MKR1000, and the board boots fine and I can run my Thing against the MKR1000 config.  I am not using D11 or D12 in my code and am not using the TwoWire lib so I am not sure why this would interfere with the Crypto config at boot up.


It's not shown on the MKR1000 schematic because it's integrated into the ATSAMW25 module, but I believe the communication between the MKR1000's SAMD21 microcontroller and the crypto authentication chip is via the I2C bus, which is on pins 11 and 12. If you connect anything to those pins that disrupts the I2C communication, it could cause the behavior you experienced. I don't know what it is about your shield that is doing that.


Yeah, the only thing I can see is that one of the Motor connections is mapped to D11 (SDA) so perhaps a connection on that pin or something on the Motor board is pulling the pin high or low.  My code is not mapping this pin or using the TwoWire lib so I do find it strange it does interfere.  I may experiment with delaying the shield initialization to let the Crypto stuff complete it's initialization.   Leaving the pins not connected is an option as well.

I have seen others having issues with getting the Crypto part of adding a board to IoT Cloud, so this might be something to look at in those instances as well.  That is ensure nothing is connected to SDA or SCL during boot of the board or Crypto config.


I have seen others having issues with getting the Crypto part of adding a board to IoT Cloud, so this might be something to look at in those instances as well.  That is ensure nothing is connected to SDA or SCL during boot of the board or Crypto config.
Good tip! I'll keep that in mind when attempting to help people with that sort of problem. I think it's a tricky thing, since people assume they can use the pins as they like without it causing any issues with the internal workings of the board. It would probably be worth adding a note about this to the documentation.

I believe the battery charger chip on the MKR GSM 1400, MKR NB 1500, MKR WiFi 1010, MKR Zero, and MKR Vidor 5000 is connected to the I2C bus as well.


Hi, I'm facing the same issue while wiring


on pins 11 & 12

How did you fix it ? Simply used other pins ?

Used 6 & 7 and... IT DID THE JOB !!!

I'm so happy !!!!


Yep, that is what I found and posted; don't use pins 11 and 12 especially if it not an i2C device since you are redefining the pins to something else.

However, this just doesn't seem right in the case of the Arduino MKR ENV Shield or MKR2UNO boards which use the SDA and SCL connections and cannot be rewired; that is unless you either hack the board or use jumpers to rewire the.   I haven't tried reading values from a i2C sensor on the MKR2UNO board with a MKR1010 attached, so it might be fine with another i2c connection. 


hi @jomoengineer

I might have a workaround for you.
We recently added callbacks for connection and disconnection events in the ArduinoIoTCloud library.

Shields and peripherals which might generate spikes in current consumption can sometimes prevent the crypto chip from starting up properly if the sequence is not managed.

I'd suggest you add a callback for onConnected and after that initialise your shield.
This is a quick example
I'm assuming a generic Motor Shield library which I'm making up a name for since you have not specified which one you are using :)

Code: [Select]

MotorShieldLibrary motorShield;
bool motorShieldInitialized = false;
void setup(){
  ArduinoCloud.addCallback(ArduinoIoTCloudEvent::CONNECT, &onConnect);

void loop(){
      // motor shield code

void onConnect(){
   motorShieldEnabled = true;

let me know if this helps out


From what I observed, when the issue is hit, it will hang within the ArduinoCloud.begin call since deep in there is where ECCX08Class::begin is called and the crypto check is performed.  If there is an issue with communicating with the crypto device, ArduinoCloud.begin does not return thus the code is stuck at this point and nothing after it will be perform.  So, anything added after ArduinoCloud.begin will never be seen.


I have seen this happen when a device is taking a lot of current and the ArduinoCloud.begin() is called.
try and first get the connection to Cloud running and then start using the motor shield.
My example above should be able to help you.

Tomorrow I'll see if I can investigate this on a library level :)



The Motor Shield and MKR1000 works as long as I keep the connections to D11 and D12 not connected from the Motor Shield.  If I did use these pins from the Motor shield, it would end up using them as non i2C pins which is an issue so leaving them not connected and not defining these pins for anything else bypasses the issue.

Outside of this, I ensure all other initialization for other pins is done after the  ArduinoCloud.begin call.

But, again, with the pins connected from the MotorShield, the board will get stuck at ArduinoCloud.begin and never returns, thus your example would have no affect since it would never get to the callback.

However, I have been successful using the i2C connections to a ADXL345 connected through a MKR Relay Proto Shield.  In this case, since the ADXL345 is another i2C device, it is not interfering with the cypto chip connection.  I do init this after ArduinoCloud.begin and after a delay of 7000 though.


hey @jomoengineer

When you issue a
Code: [Select]
begin() but then use the i2c bus for other purposes things may go South if these operations are too close.

Would you have the chance to try and only initialise/use the shield once the connection to IoT Cloud is established?
Essentially adding callbacks serves such purposes, and by being notified you can begin using your hardware only once the connection done, without having to worry about interfering with i2c.

Anyway this should be addressed at a library level, so I'll talk to my colleagues and see what we can come up with :)


I don't see the point.   As I have stated, I am not initializing the Shield prior to the ArduinoCloud.begin; just having the Shield connected causes a problem.  Also, I have a delay(7000) after the begin but the hang occurs prior to this within the ArduinoCloud.begin.  I had added debug messages tracking it back to the ECCX08Class calls where the crypto chip is checked and it never returns.  Pulling the pins from the Shield connection to the MKR1000 resolves the issue, so I am okay with this. 


We'll add a timeout on the ECC init which triggers an error.
This will at least notify the user with a clearer troubleshooting message.

Thank you for investigating, @jomoengineer :)

Go Up