NOTE: Breakout board just refers to a board that is an isolated implementation of a part of a subsystem for testing and development in an isolated manner. It is not intended to be a part of the actual final design of the satellite.

Link to the Load Switch breakout on Alitum:

https://americas-uworbital-university-of-waterloo.365.altium.com/designs/33844F92-6E1E-45BB-8851-1FB03FBD4909?activeView=SCH&variant=[No+Variations]&activeDocumentId=load20switch.SchDoc&location=[1,97.03,17.61,30.8]#design

Task: Write INA230/TCA6424 Driver and test the overall Load Switch system using the breakout board.

The breakout board has 3 main components: the load switch (SIP32408), the current shunt (INA230), and the IO Expander (TCA6424).

The following questions help in understanding the system from a high level:

• Start by understanding each component and the overall system.
  • What is this system trying to do?
    • We are trying to control power being sent to a subsystem (this is what the load switch does), and monitor the current being supplied through the load switch (this is what the INA230 does)
  • Why is an IO Expander (TCA6424) necessary?
    • We need to read input (I assume) as GPIO from the INA230 ALERT pin
    • We need to give output as GPIO to enable the SIP32408 load switch
    • This would take multiple GPIO pins, and we would have multiple of these load switches/current shunts in the system. Thus to preserve pins, we communicate with the TCA6424 through I2C, which essentially acts as a middleman for our GPIO needs (we can hook up in theory infinite devices to I2C, limited by unique addresses)
  • Why is a load switch necessary?
    • Think of this as just a switch to allow current through based on a GPIO output from some source on its EN pin
  • Why is the INA230 necessary?
    • This is the tool we use to read/monitor the power/current/voltage coming through the load switch
• What is a general flow (I.E. what triggers what?)
  • It looks like we enable the SIP through a general purpose output (I2C command from the MCU to the TCA6424 to turn the pin connected to SIP EN on)
  • This activates the load switch and allows power through the output port of the SIP
  • This goes to the IN+ terminal of the INA230 to be measured.
    • The INA230 measures the voltage difference across this resistor (the IN- terminal is linked directly to a header pin, and the BUS pin of the INA230), we can use I = V/R to find the current (probably have to give the INA230 the resistance we are using)
  • We can then send I2C commands to read the measurements current/voltage measurements of the INA230 (and thus the power coming from the load switch).
  • We can also configure the Alert pin on the INA230 to send output if the reading is above/below a threshold
• What parts interact with the MCU?
  • TCA6424 - I2C commands and GPIO(?)
    • QN: how are GPIO inputs from the TCA6424 read by the MCU? through GPIO or I2C?
      • E.g. ALERT on INA goes off → TCA6424 reads the output → how is it sent from the TCA6424 to the MCU?
  • SIP - We trigger an output from the TCA to the SIP using I2C commands
    • QN: how else can we get the TCA to trigger? Periodically maybe?
  • INA230 - configure/read using the I2C. Alerts sent as GPIO from ALERT pin to the TCA6424
• Generally, when do we need to send commands or read values from the INA230? What do we do with these values?
  • This is more of a system level question. Kind of out of scope for a driver.

Simple test we can do for basic functionality:

• Send I2C command to TCA6424 to go HIGH on P01 (connected to EN of SIP 1)
  • Measure using test point to ensure TCA6424 actually drove high. If not, errors with configuration/communication with the TCA6424
• Send I2C command to INA230 for its measured values. Ensure this is correct (calculate what it should be using IN+, IN- and the resistor value between these).
• Send I2C command to TCA6424 to go LOW on P01
  • Ensure using the test point that it drove low
  • Ensure INA230 measurement adjusts appropriately

TO TEST INA230 ALERT:

• Configure alert to some low value that we are sure to exceed
  • Confirm that ALERT went off using test point
  • Confirm that the MCU was signaled that ALERT went off
  • If either of the above don’t occur, something is wrong
  • Turn off load switch so INA should not be measuring any positive value
  • Ensure that ALERT is off now