26 January 2020

Unhappy with yesterday’s failed test, we decided to investigate further. We did find a couple of omissions on our board. The reason the MCU couldn’t see the I2C devices is rather simple: the I2C clock and data wires weren’t connected to the MCU!

We also realised that one of the ends of the Cat6 cable we used to connect the MPU was wired using a different version of the cabling standard. T-568A versus T-568B.

This was rather positive. However, our MCU still wasn’t recognising inputs correctly. The Arduino Pro Micro we are using seem to be responding correctly or to be picking up interrupts.

We tried cleaning up our code a little but to no avail. We also realised that using interrupts on pins 0 and 1 was causing us problems uploading new code to the MCU. These are the RX/TX pins and, while is is ok to use them for other things, our code was conflicting with the functioning of the USB port.

This is what we observed:

  • If the board is powered through the USB port only with our little power module not connected to its power supply but connected to the board, everything works fine. The PC recognises the MCU and can see the MPU6050 moving. Unfortunately, the MCU does not provide enough current per pin to power but there’s not enough current for the LCD or LED strip so it’s not a good option. So we have to be able to use the MCU with an external power supply
  • If the board is connected through USB and through the power module, nothing happens and the PC doesn’t recognise the board anymore.
  • If the board is connected through the power module only… well, there’s no cable between the board and the PC and magic doesn’t work either…

We checked and re-checked the datasheets, checked for information online but couldn’t work out where our problem came from. As our MCU’s power regulator can accept up to 16V (12V recommended), we connected a 12V power supply to the MCU. This immediately produced the magic blue smoke! A second attempt caused one of the on-board resistors to spark on the MCU. We concluded that that MCU board was no longer usable!

Rather than break another board, we decided to try with one of our Arduino Leonardo boards we used for the prototype. This worked and produced mostly expected results (bugs notwithstanding).

After some further reading and discussion, we decided that we needed to find solutions to 2 problems:

  1. Power supply: how can we power the boards and the MCU at the same time without breaking our MCU?
  2. I/O pins and interrupts: how can be have enough interrupts and I/O pins if we cannot use pins 0 and 1?

26 January 2020