This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MCT8316A: Condition writing and reading from shadow RAM to EEPROM

Part Number: MCT8316A

Tool/software:

Hi support team all.

We have received the following inquiry from a customer.
We would appreciate your cooperation.

1. What are the conditions for saving from shadow RAM to EEPROM?

According to the information from E2E, it is understood that the status must be "MOTER_IDLE (06h)", but is it completely impossible for it to be in any other status?
Please tell me if there are any other conditions besides the status.

2. What are the conditions for reading from EEPROM to shadow RAM?

There is no clear information on this.
We have confirmed that reading is not possible in the "SYSTEM_IDLE (00h)" status.
Are the conditions the same as when writing?

Best regards,

Higa

  • Hi Higa-san,

    1. The MCT8316A allows EEPROM write and read operations as long as the motor is not spinning. So if there's a fault flag and the motor is not spinning, the user can still trigger an EEPROM write operation.
    2. An EEPROM read operation is triggered by writing 0x40000000 into register 0xE6 when the motor is not spinning. The condition is the same as writing to EEPROM, the different is simply the bits written into register 0xE6

    Regards,
    Eric C.

  • Hi Eric-san

    We check SYS_STATUS2 to determine the state in which it is possible to write to or read from the EEPROM.
    We need to know through I2C communication when the motor is not rotating, is this the correct way to do it?

    If it is correct, in what state is SYS_STATUS2 possible to write and read?

    When you say a state in which the motor is not rotating, I would think that writing would be possible in the SYSTEM_IDLE or MORTOR_BRAKE states, but in reality this is not the case.

    Currently we are experiencing many cases where it is not possible to write to the EEPROM, and we are at risk of losing business.

    We would appreciate your cooperation.

    Best  regards,

    Higa

  • Hi Higa-san,

    Slight correction, the EEPROM read/write operation can complete successfully only when the device is NOT actively driving any of the internal FETs. When the device is in MOTOR_BRAKE state, it's either turning on all 3 high-side FETs or all 3 low-side FETs, so EEPROM read/write won't be possible.

    However, there was an issue that we've seen before where the device might get stuck in MOTOR_BRAKE state on power-up if the STL_ENABLE bit is accidentally set in the device EEPROM. If this is the case, the STL_ENABLE bit needs to be cleared from the device EEPROM to prevent the device from getting stuck in MOTOR_BRAKE. Please refer to this post: https://e2e.ti.com/support/motor-drivers-group/motor-drivers/f/motor-drivers-forum/1122918/mct8316aevm-device-not-work-after-write-register-value-to-eeprom/4166206#4166206

    Problem:
    If [BRAKE_INPUT] = 00b and [STL_ENABLE] = 1b in EEPROM, then the device will get stuck in MOTOR_BRAKE mode after power-up.

    Fix:
    To clear the [STL_ENABLE] bit:

    1. Set [BRAKE_INPUT] = 10b
    2. Set [STL_ENABLE] = 0b
    3. Write register to EEPROM
    4. Power cycle
    5. Set [BRAKE_INPUT] back to 00b
    6. Write register to EEPROM again

    The STATE register should report MOTOR_IDLE when the algorithm is in idle standby mode, rather than SYSTEM_IDLE. Could you please help ask the customer when they observe [STATE] = SYSTEM_IDLE?

    Regards,
    Eric C.

  • Hi Eric-san

    I'm sorry I pressed Solve by mistake.
    I have some additional question.

    - If I am not using the brake hard terminal input, are steps 4, 5, and 6 not necessary?

     - What are the conditions for entering the SYSTEM IDLE state?

    Regards,

    Higa

  • Hi Higa-san,

    1. If you are not using hardware pin Brake input, then steps 4,5,6 are not necessary, and you can leave BRAKE_INPUT as 10b. The last 3 steps are simply there to restore BRAKE_INPUT to its previous value 00b.
    2. I haven't observed the device being in SYSTEM_IDLE state myself. I think SYSTEM_IDLE is the status of the state machine before the device boots up. Immediately after power-up, device initializes certain critical variables as part of bootup.

      This is why I was curious what condition do you see the device report SYSTEM_IDLE? Do you see this after powering up the device? Does your device ever enter into MOTOR_IDLE state?

    Regards,
    Eric C.

  • Hi Eric-san

    We have attached the data we have obtained from reading address EAh after powering on.
    When we obtained this data, the state did not change from SYSTEM_IDLE.
    For comparison, we have also shared data from another unit that is in MOTOR_IDLE in another tab, so please refer to that.

    Is it possible that we mistakenly wrote to a register that should not be written to in the configuration file we sent you the other day?
    As far as we can tell, we were not accessing any registers that should not be written to according to the data sheet.

    Let me ask again, what are the conditions for entering SYSTEM_IDLE?

    This issue is extremely critical and is a major obstacle to continuing mass production.

    Best regards,

    Higa

    SYSTEM_IDLE data.xlsx

  • Hi Higa-san,

    I've confirmed with our firmware team that SYSTEM_IDLE is the default state during firmware initialization. After initialization, the firmware will then enter into MOTOR_IDLE state when it's ready to receive speed command.

    I'm not aware of any user registers that could cause the device to get stuck in SYSTEM_IDLE state. Please let me discuss further with our firmware and system team, and I'll get back to you ASAP.

    Regards,
    Eric C.

  • Hi Higa-san,

    The device getting stuck in SYSTEM_IDLE appears to be an abnormal behavior that we haven't encountered before. It would indicate that the device firmware failed to complete basic initializations. How many devices do you have that are getting stuck in SYSTEM_IDLE?

    I don't recall the configuration file that you sent be before, could you please share again?

    Is it also possible for you to read all registers values on the device that's stuck in SYSTEM_IDLE and send the entire device register settings to me (reg address  + value)?

    Thanks.

    Regards,
    Eric C.

  • Hi Eric-san

    We received register information from the customer.
    This is register information for all addresses showing a status of SYSTEM_IDLE.

    Regards,

    Higa

    {
      "signature": "oneui-register-data",
      "data": [
        [
          {
            "idx": 0,
            "id": "isd_config",
            "value": "0x64738C20"
          },
          {
            "idx": 1,
            "id": "motor_startup1",
            "value": "0x28200000"
          },
          {
            "idx": 2,
            "id": "motor_startup2",
            "value": "0x0B6807D0"
          },
          {
            "idx": 3,
            "id": "closed_loop1",
            "value": "0x2306600C"
          },
          {
            "idx": 4,
            "id": "closed_loop2",
            "value": "0x0D3201B5"
          },
          {
            "idx": 5,
            "id": "closed_loop3",
            "value": "0x1BAD0000"
          },
          {
            "idx": 6,
            "id": "closed_loop4",
            "value": "0x00000000"
          },
          {
            "idx": 7,
            "id": "const_speed",
            "value": "0x00000000"
          },
          {
            "idx": 8,
            "id": "const_pwr",
            "value": "0x3EC80106"
          },
          {
            "idx": 9,
            "id": "150_deg_two_ph_profile",
            "value": "0x00000000"
          },
          {
            "idx": 10,
            "id": "150_deg_three_ph_profile",
            "value": "0x00000000"
          },
          {
            "idx": 11,
            "id": "trap_config1",
            "value": "0x000D0000"
          },
          {
            "idx": 12,
            "id": "trap_config2",
            "value": "0x00000000"
          }
        ],
        [
          {
            "idx": 0,
            "id": "fault_config1",
            "value": "0x70D00888"
          },
          {
            "idx": 1,
            "id": "fault_config2",
            "value": "0x00000000"
          }
        ],
        [
          {
            "idx": 0,
            "id": "gd_config1",
            "value": "0x1C450100"
          },
          {
            "idx": 1,
            "id": "gd_config2",
            "value": "0x14200000"
          }
        ],
        [
          {
            "idx": 0,
            "id": "pin_config1",
            "value": "0x00000000"
          },
          {
            "idx": 1,
            "id": "pin_config2",
            "value": "0x00101462"
          },
          {
            "idx": 2,
            "id": "device_config",
            "value": "0x4000F00F"
          },
          {
            "idx": 3,
            "id": "peri_config",
            "value": "0x41C01F00"
          }
        ],
        [
          {
            "idx": 0,
            "id": "ana_trim3",
            "value": "0x48004800"
          },
          {
            "idx": 1,
            "id": "ana_trim4",
            "value": "0x00000000"
          },
          {
            "idx": 2,
            "id": "ana_trim5",
            "value": "0x000003EF"
          },
          {
            "idx": 3,
            "id": "ana_trim6",
            "value": "0x00000000"
          },
          {
            "idx": 4,
            "id": "ana_trim7",
            "value": "0x00000000"
          },
          {
            "idx": 5,
            "id": "ana_trim8",
            "value": "0x00000A32"
          },
          {
            "idx": 6,
            "id": "ana_trim9",
            "value": "0x00A5E860"
          },
          {
            "idx": 7,
            "id": "ana_trim10",
            "value": "0x536CF03B"
          }
        ],
        [
          {
            "idx": 0,
            "id": "algo_reserved1",
            "value": "0x00000000"
          },
          {
            "idx": 1,
            "id": "algo_reserved2",
            "value": "0x2433407D"
          },
          {
            "idx": 2,
            "id": "algo_reserved3",
            "value": "0x000001A7"
          }
        ],
        [
          {
            "idx": 0,
            "id": "gate_driver_fault_status",
            "value": "0x00000000"
          },
          {
            "idx": 1,
            "id": "controller_fault_status",
            "value": "0x00000000"
          }
        ],
        [
          {
            "idx": 0,
            "id": "sys_status1",
            "value": "0x00000000"
          },
          {
            "idx": 1,
            "id": "sys_status2",
            "value": "0x00010000"
          },
          {
            "idx": 2,
            "id": "sys_status3",
            "value": "0x536CF03B"
          }
        ],
        [
          {
            "idx": 0,
            "id": "device_ctrl",
            "value": "0x00000000"
          }
        ],
        [
          {
            "idx": 0,
            "id": "algo_ctrl1",
            "value": "0x00000000"
          }
        ]
      ]
    }
    
    

  • Hi Higa-san,

    Please let me review the register settings, and I'll get back to you.

    Were you able to confirm with the customer how many devices are getting stuck in SYSTEM_IDLE after powering up?

    Regards,
    Eric C.

  • Hi Eric-san

    12 units.

    Regards,

    Higa

  • Hi Eric-san

    Do you have any update?

    We are receiving complaints from customers about this issue.
    If we don't find a solution quickly, we could lose this important business opportunity.

    Best regards,

    Higa

  • Hi Higa-san,

    The register map provided above still has the STL_ENABLE bit enabled.

    When I wrote the customer's register settings into my MCT8316EVM, I see that the device STATE gets stuck in MOTOR_BRAKE due to the previous issue, but I don't observe the SYSTEM_IDLE state. Once I've cleared the STL_ENABLE bit using the steps I provide above, the device returns to MOTOR_IDLE state.

    Could you please make sure that they've disabled the STL_ENABLE bit based on the previous instruction that I provided?

    I've also checked with our firmware engineer who developed the MCT8316A's algorithm, and he couldn't think of a scenario that could cause the device to get stuck in SYSTEM_IDLE.

    If you are able to confirm that the STL_ENABLE bit is NOT set, and the STATE is still stuck in SYSTEM_IDLE, then can you please do an ABA swap between a good board and a bad board and see if the issue follows the IC or the PCB?

    Regards,
    Eric C.

  • Hi Eric-san

    We have confirmed with our customer.

    There was no change even when STL_ENABLE was disabled.

    Below is a summary of what we have confirmed so far.

    we have also checked some additional things here.

    ① The state when SYSTEM_IDLE was confirmed
    ・DRVOFF=H: The system was powered on with the DRVOFF input pulled up (fixed by a circuit).
    ・Device settings were in the factory settings (no write access to shadow RAM or EEPROM)
    ・Occurred in 12 devices

    ② The state when the device in ① changed from SYSTEM_IDLE to MOTOR_IDLE
    ・DRVOFF=L: The system was powered on with the DRVOFF input pulled down (fixed by a circuit).
    ・Device settings remained in the factory settings (no write access to shadow RAM or EEPROM)

    Here is a question.

    1. Is there a problem with powering on with DRVOFF=H? If there is a problem, please tell me the reason.
    (It is not stated in the data sheet)

    2. There were cases where the device could not transition from SYSTEM_IDLE when powering on with DRVOFF=H.

    Are there really no conditions for the device to enter SYSTEM_IDLE?

    In the datasheet, there is no explanation other than that DRVOFF sets the output to Hiz, so it is difficult to guess the relationship.

    3. Is it a problem that it becomes SYSTEM_IDLE at startup?

    In most devices, the status seems to change from SYSTEM_IDLE to MOTOR_IDLE at normal startup.

    4. Do you know the approximate time it takes for it to change from SYSTEM_IDLE to MOTOR_IDLE?

    Currently, it seems to take about 100ms to several hundred ms.

    5. Please tell me the data of the EEPROM in the shipping state.

    Best regards,

    Higa

  • Hi Higa-san,

    I've sent you an email to take the next steps offline.

    Regards,
    Eric C.