MCF8316A: Driver stops working while reading register with i2c

Hi Oliver,

We have an errata related to this issue. Can you set the PWM output frequency [PWM_FREQ_OUT] to 35 kHz or 65 kHz? If you still see this issue, then there is no other workaround to resolve this issue. Can you use FG to know the rotor position? 

Regards,

Vishnu

Hi Vishnu,

I already tried others PWM output frequency, but the problem still happen. I'm considering to use FG, but I've choosen MCF for the possibilit to read registers with i2c.

Can you recommend other brushless driver with integrated FETs? Is there any possibility of releasing a version with the i2c working correctly or the DAC outputs?

Regards,

Oliver

Oliver,

We will be releasing the B version of the same device with all the bug fixes by 3Q 2022. Unfortunately, this is the only device that has the capability to output real time rotor angle information. 

Regards,

Vishnu 

Hello Vishnu, 

I work with Oliver and Ricardo and we made further tests here. Below I will describe everything that we've done so far and also share some data about the tests.

1) About our hardware setup:

We are using the evaluation board MCT8316AEVM with the driver chip replaced with the MCF8316A1VRGFR model.

The motor that we are using have the following parameters:

2) Initial Test using GUI:

2.1 Test Setup

Using the setup above and the GUI provided by TI we started to experience some spourious motor locks, so the screen stops working and the motor stops or stayed in a fixed speed, and only if we make a power up cycle on the MCF8316 it returned to operate. This is easy to occur and the steps are listed below how to reproduce:

1.Use MCF8316A GUI 1.1.5;

2.Connect to Computer;

3.Connect to the GUI;

4. On <File> and <load registers>: Load the file “110322_1_5_test18_i2cregs.json”;

{
  "signature": "oneui-register-data",
  "data": [
    [
      {
        "idx": 0,
        "id": "isd_config",
        "value": "0x04638C20"
      },
      {
        "idx": 1,
        "id": "rev_drive_config",
        "value": "0x283AF064"
      },
      {
        "idx": 2,
        "id": "motor_startup1",
        "value": "0x628E1140"
      },
      {
        "idx": 3,
        "id": "motor_startup2",
        "value": "0x23002134"
      },
      {
        "idx": 4,
        "id": "closed_loop1",
        "value": "0x5F32813C"
      },
      {
        "idx": 5,
        "id": "closed_loop2",
        "value": "0x2AAD5366"
      },
      {
        "idx": 6,
        "id": "closed_loop3",
        "value": "0x1D800000"
      },
      {
        "idx": 7,
        "id": "closed_loop4",
        "value": "0x3106CF60"
      },
      {
        "idx": 8,
        "id": "speed_profiles1",
        "value": "0x00000000"
      },
      {
        "idx": 9,
        "id": "speed_profiles2",
        "value": "0x00000000"
      },
      {
        "idx": 10,
        "id": "speed_profiles3",
        "value": "0x00000000"
      },
      {
        "idx": 11,
        "id": "speed_profiles4",
        "value": "0x00000000"
      },
      {
        "idx": 12,
        "id": "speed_profiles5",
        "value": "0x00000000"
      },
      {
        "idx": 13,
        "id": "speed_profiles6",
        "value": "0x00000000"
      }
    ],
    [
      {
        "idx": 0,
        "id": "fault_config1",
        "value": "0x7FFC7A46"
      },
      {
        "idx": 1,
        "id": "fault_config2",
        "value": "0x74147F50"
      }
    ],
    [
      {
        "idx": 0,
        "id": "pin_config",
        "value": "0x00000002"
      },
      {
        "idx": 1,
        "id": "device_config1",
        "value": "0x10100000"
      },
      {
        "idx": 2,
        "id": "device_config2",
        "value": "0x4000F00E"
      },
      {
        "idx": 3,
        "id": "peri_config1",
        "value": "0x01A00200"
      },
      {
        "idx": 4,
        "id": "gd_config1",
        "value": "0x1C010E00"
      },
      {
        "idx": 5,
        "id": "gd_config2",
        "value": "0x03400000"
      }
    ],
    [
      {
        "idx": 0,
        "id": "ana_trim3",
        "value": "0x48004800"
      },
      {
        "idx": 1,
        "id": "ana_trim4",
        "value": "0x00000000"
      },
      {
        "idx": 2,
        "id": "ana_trim5",
        "value": "0x000003ED"
      },
      {
        "idx": 3,
        "id": "ana_trim6",
        "value": "0x00000000"
      },
      {
        "idx": 4,
        "id": "ana_trim7",
        "value": "0x00000000"
      },
      {
        "idx": 5,
        "id": "ana_trim8",
        "value": "0x00000461"
      },
      {
        "idx": 6,
        "id": "ana_trim9",
        "value": "0x00A9A89D"
      },
      {
        "idx": 7,
        "id": "ana_trim10",
        "value": "0x536AF13B"
      }
    ],
    [
      {
        "idx": 0,
        "id": "int_algo_1",
        "value": "0x24B1407D"
      },
      {
        "idx": 1,
        "id": "int_algo_2",
        "value": "0x00000161"
      }
    ],
    [
      {
        "idx": 0,
        "id": "gate_driver_fault_status",
        "value": "0x00000000"
      },
      {
        "idx": 1,
        "id": "controller_fault_status",
        "value": "0x00000000"
      }
    ],
    [
      {
        "idx": 0,
        "id": "algo_status",
        "value": "0x2450AF50"
      },
      {
        "idx": 1,
        "id": "mtr_params",
        "value": "0x00000000"
      },
      {
        "idx": 2,
        "id": "algo_status_mpet",
        "value": "0x00000000"
      }
    ],
    [
      {
        "idx": 0,
        "id": "dev_ctrl",
        "value": "0x20000000"
      }
    ],
    [
      {
        "idx": 0,
        "id": "algo_ctrl1",
        "value": "0x80000000"
      },
      {
        "idx": 1,
        "id": "algo_ctrl2",
        "value": "0x00000000"
      },
      {
        "idx": 2,
        "id": "current_pi",
        "value": "0x000A0AB6"
      },
      {
        "idx": 3,
        "id": "speed_pi",
        "value": "0x00000000"
      },
      {
        "idx": 4,
        "id": "dac_1",
        "value": "0x00000000"
      },
      {
        "idx": 5,
        "id": "dac_2",
        "value": "0x00000000"
      }
    ],
    [
      {
        "idx": 0,
        "id": "algorithm_state",
        "value": "0x0012000D"
      },
      {
        "idx": 1,
        "id": "fg_speed_fdbk",
        "value": "0x05CBAD10"
      },
      {
        "idx": 2,
        "id": "bus_current",
        "value": "0x000232DB"
      },
      {
        "idx": 3,
        "id": "phase_current_a",
        "value": "0x00200000"
      },
      {
        "idx": 4,
        "id": "phase_current_b",
        "value": "0x00010000"
      },
      {
        "idx": 5,
        "id": "phase_current_c",
        "value": "0xFFDF0000"
      },
      {
        "idx": 6,
        "id": "csa_gain_feedback",
        "value": "0x00010003"
      },
      {
        "idx": 7,
        "id": "voltage_gain_feedback",
        "value": "0x00000001"
      },
      {
        "idx": 8,
        "id": "vm_voltage",
        "value": "0x03434000"
      },
      {
        "idx": 9,
        "id": "phase_voltage_va",
        "value": "0x00000000"
      },
      {
        "idx": 10,
        "id": "phase_voltage_vb",
        "value": "0x00000000"
      },
      {
        "idx": 11,
        "id": "phase_voltage_vc",
        "value": "0x00000000"
      },
      {
        "idx": 12,
        "id": "sin_commutation_angle",
        "value": "0xF90EBA5C"
      },
      {
        "idx": 13,
        "id": "cos_commutation_angle",
        "value": "0x03F8D4B4"
      },
      {
        "idx": 14,
        "id": "ialpha",
        "value": "0x00200000"
      },
      {
        "idx": 15,
        "id": "ibeta",
        "value": "0x0013A141"
      },
      {
        "idx": 16,
        "id": "valpha",
        "value": "0x00328AEC"
      },
      {
        "idx": 17,
        "id": "vbeta",
        "value": "0x001AD80A"
      },
      {
        "idx": 18,
        "id": "id",
        "value": "0xFFFD80AC"
      },
      {
        "idx": 19,
        "id": "iq",
        "value": "0x002568C3"
      },
      {
        "idx": 20,
        "id": "vd",
        "value": "0x0001CCBC"
      },
      {
        "idx": 21,
        "id": "vq",
        "value": "0x0039364A"
      },
      {
        "idx": 22,
        "id": "iq_ref_rotor_align",
        "value": "0x00000000"
      },
      {
        "idx": 23,
        "id": "speed_ref_open_loop",
        "value": "0x00000000"
      },
      {
        "idx": 24,
        "id": "iq_ref_open_loop",
        "value": "0x00000000"
      },
      {
        "idx": 25,
        "id": "speed_ref_closed_loop",
        "value": "0x00000000"
      },
      {
        "idx": 26,
        "id": "id_ref_closed_loop",
        "value": "0x00000000"
      },
      {
        "idx": 27,
        "id": "iq_ref_closed_loop",
        "value": "0x00000000"
      },
      {
        "idx": 28,
        "id": "isd_state",
        "value": "0x00000000"
      },
      {
        "idx": 29,
        "id": "isd_speed",
        "value": "0x00000000"
      },
      {
        "idx": 30,
        "id": "ipd_state",
        "value": "0x00000000"
      },
      {
        "idx": 31,
        "id": "ipd_angle",
        "value": "0x00000000"
      },
      {
        "idx": 32,
        "id": "ed",
        "value": "0x00000000"
      },
      {
        "idx": 33,
        "id": "eq",
        "value": "0x00000000"
      },
      {
        "idx": 34,
        "id": "speed_fdbk",
        "value": "0x00000000"
      },
      {
        "idx": 35,
        "id": "theta_est",
        "value": "0x00000000"
      }
    ]
  ]
}

5.Click on  “All tuning Setting”;

6.Enable “Speed Control via I2C”;

7.Enable “Auto Read Fault Status”;

8.Enable “Auto Read Motor Status”;

9.Start running the motor on “I2C Speed Command Percentage”;

10. Configure to around 25% and wait a random time to occur the issue (less than 10 minutes);

2.2 Analysis of I2C

To be sure about the origin of this problem we inspected the I2C lines to see whats happens when the device crashes.

With the GUI using the test setup (2.1) we can see that the microcontroller asks for data each 125 ms to the MCF8316A.

When the crash occurs we can see a sequence of NAKs happening and then the GUI application disconnects from target and the MCF8316A stay locked in fixed speed. Interesting things:

1) Only after a power cycle of MCF8316A it will work again

2) If we reset only the microcontroller from the board the MCF8316A does not work, it needs a power cycle of MCF8316A to work again.

The picture related to the behavior of the NAKs is below:

After recording this waveform we notice that the timing associated with the I2C is out of specification regard to time between I2C bytes.

In page 71 we have a note in section 7.6.2 that state as follow: "For reliable communication, a 100-µs delay should be used between every byte transferred over the I2C bus."

After reading this we are sure that the embedded software provided by Texas in not compliant with this statement, to check if this could be the reason to continuous NAKs in I2C bus we got a base software of the eval in the topic of forum, and modifying the code we implemented the 100us delay between the I2C communication bytes.

With the new software in the microcontroller evaluation we didn't notice any other NAK behavior, however, we still see some locks.

The firmware code and binary file are at the end of page, the firmware is the i2c_test_GUI_1_1_5.out.

2.3 Tests with modified firmware (100us delay) an GUI:

As said above, after adding the 100us delay the device did not experienced any other NAK issue, however we stiil see that the motor stops.

In this case this is whats happens when the crash occurs and the device stop spinning:

1) GUI does not disconnect

2) Device reports fixed angular position (THETA_EST)

3) Device reports speed zero or the last speed before crash

4) I2C communication continues

5) No error flag is reported

6) If we try to change the speed the device does not respond to this command and stay stopped.

After this test it seems that for some reason the driver stops working and did not accept further speed commands, leading us to a problem that this IC will lock and will not be able to recover itself and resume spinning.

With several tests performed we also observed happening (rarely) some lock downs on I2C, and we couldn't tell if it was the microcontroller or MCF8316A that crashed the I2C bus, the picture below illustrate the problem that we saw:

2.4 Tests with modified firmware (100us delay) without GUI:

After the tests above we modified the firmware of the MSP on the evaluation board to perfom a simple task of setting the speed to determined value and keep reading speed and position only. The firmware executes the following routine:

1) Set the Speed to 25,81%

2) Read speed (0x0752)

3) wait 4 ms

4) Read THETA_EST (ox0756)

5) wait 4ms

6) repeat step 2

The steps to reproduce are the following:

1. Flash the evaluation module with firmware “i2c_test_uc_speed_read.out”;

2.Connect the evaluation module to Motor;

3.Turn on the evaluation module;

• The motor will run about 172 Hz.

4.Using a digital oscilloscope we added spies on I2C line and Fgout.

Below are some picture of I2C lines and FGOUT(orange trace):

So, we faced another issue, when the motor was running and we were reading the speed and theta register, suddenly the motor stopped, without fault , and we couldn't more run the motor until the driver to be reset (I2C still have communication normally).

Here below are some important point about this test:

Messages used to communicate with driver below:

• Set speed (25%):
  • (0x02,0x50,0x00,0xEC,0x00,0x00,0x09,0xA1,0x15)
• Read SPEED_FDBK
  • (0x02,0xD0,0x07,0x52)
• Read THETA_EST
  • (0x02,0xD0,0x07,0x56)

We are using 35KHz on PWM output frequency [PWM_FREQ_OUT], how was recommend.

The modified firmware is available on folder “i2c_test” (ccs project). The binary file is i2c_test_uc_speed_read.out compressed inside i2c_test_firmwares.zip

The configuration of the MCF8316A registers is available on file “110322_1_5_test18_i2cregs.json” .(GUI 1.1.5) presented above.

After running this test we also implemented a speed setting command if we detect the lock of the motor, but as the test with the GUI, the motor keeped stopped and the command had no effect.

2.5 Binary Files and project:

Here we have the project in css with 2 builds related to original code with 100us delay and the modified one used in 2.4 test.

i2c_test.zip

The original code was found here:

(+) MCT8316AEVM: Where can I get “MCT8316AEVM_MSP430FR2355_Firmware_GUI.zip”？ - Motor drivers forum - Motor drivers - TI E2E support forums

Just to make it easier here we have the binary of the 2 software:

1) Firmware of MSP using the GUI with 100us delay between I2C bytes (i2c_test_GUI_1_1_5.out)

2) Firmware running on test 2.4 - speed setting and continuous read (i2c_test_uc_speed_read.out)

i2c_test_firmwares_out.zip

l will get back to you shortly!

Hello Vishnu,

The "auto read motor status" and "auto read device status" is related to the GUI tests problems, and it is problematic because the EVM and basic software provided by Texas don’t work...

A simple test on the workbench for more than 10 minutes would expose these problems, the embedded software project, which are not following what is stated in the datasheet, as well as the strange behaviors when motor is running.

The problem as it seems is deeper and worries me. These checkboxes only enable the board microcontroller to read in 125ms interval some registers from the MCF8316A, that a huge interval for an embedded system, and if the device fails in such simple operation, we cannot expect that work in a more aggressive embedded application.

As shown in the tests that I report above, the I2C stays working (when implemented the byte intervals according to the datasheet) but the motor stops running, and keep losing itself after some time, locking and not resuming the operation. Only after a power reset the device start working again.

This IC is really a good promise, but in resume we cannot count with I2C communication during operation, because of some RAM read issue that you reported, in problems like that I would expect some wrong values but not a chip lockup.

I’m not sure if the errata item number 8 of the production silicon is related to it, because the suggested action does not work, if the reality is that the register cannot be read during motor spin, another item in errata should be added, informing the user that there is no action to be taken when this kind of fault occur.

Probably you need to have another item in errata also, like I presented and you can test also, apparently when respecting the timing limits of I2C the device continues communication, but the motor can have problems during operation, like locking the motor and don´t communicate the issue, needing a reset of chip power.

In my application, without the I2C interface working during operation, will be needed to provide around 6 more pins to control the device and we loose the ability to read some variables with the maximum precision that the chip provide. In resume, without the DACOUT (that was removed in some revision) and the I2C reading this chip narrow its application to really simple applications, similar to others in the market, and with lower risks…

Now, thinking about the scenario presented by Texas, I will need to provide around 8 pins to control the device as a standard device, I will use only the I2C to configure the device before running, start the motor using a PWM signal, and monitor using FG output during running…

Ok, but with the I2C speed command not working while running, in applications that need continuous setpoint application, it seems to me that there is a possibility that in this scenario, even using the PWM input of MCT8316A can stop working. As shown in the datasheet the speed command is processed from 4 types of inputs and will generate a setpoint to the controller, probably in RAM.

In resume, I need more information about the problem, if it is mapped and the expected date to solve them. Also, I need more explanation about the PWM frequency, we used the frequency indicated by you in all of our tests, however the problem of the PWM frequency is related to the IC, or to some problem related to the Evaluation and its filters? That is really important because we are design a board with this IC, and this information is valuable.

So for further steps I need more detailed information to help me take the decision regard to continue using this chip or not, and also the expected date to this solutions:

• The frequency of PWM (that is always pointed as a problem) is related to internal circuitry and interference, or is related to the EVM board?
• It is mapped the I2C communication problem (during spinning) and locking of the motor in the roadmap of fixes? There is any date to fix this issue?
• There will be any revision of the errata, and also an official publication on the product website, instead of the forum? There is any release date expected for this errata?
• What is the roadmap and expected errata items that will be fixed in the next deliveries, like Q3 and Q4? There is any official roadmap that can be shared with the clients that use this chip?
• There is some expected date to release a new software of the GUI and the embedded software to fix some of the problems related here? Including the embedded software that are not following the device datasheet?
• There is any possibility that updating the setpoint when using the input PWM constantly like I pointed in the text above can generate a fault similar to what we are observing? This problem is self-contained in the I2C or is related to RAM, and we have the same risks here also?

Please, if possible I'm waiting the answers for this questions to take a decision here in our development.

Best Regards.

Igor

Hi Igor,

Our field team will be in touch with you sooner to setup a call with us. 

Regards,

Vishnu