MCT8316ZTEVM: Brake Mode Register in SPI Mode

Hello Jerome,

Let's try to resolve the issue with the BRAKE register bit not working, then we can circle back to discuss the BRAKE_MODE bit, as I too will need to look more into the function of the bit. 

You mention that the BRAKE register doesn't seem to be working, but that the COAST register seems to be working. What led you to this conclusion? Did you try to write a 1 to the BRAKE bit of CONTROL_7 register and you read the register value back and the bit didn't change? Or is it that you didn't notice the motor braking when you wrote to the BRAKE bit, but you did notice the motor coasting immediately after you wrote to the COAST bit?

Regards,

Anthony Lodi

Hi Anthony,

I applied a PWM to get the motors spinning. I then wrote a 1 to the brake bit of CONTROL_7 and I read the register back to confirm that it did indeed set properly. The motor continued to spin.

When I do the same thing but writing a 1 to the coast bit instead, the motor stops properly and I confirmed with the oscilloscope that the motor freewheels to a stop.

Hi Jerome,

Could you confirm the value of the BRAKE_MODE bit during the test when you wrote a 1 to the BRAKE bit? I want to see if the BRAKE_MODE bit determines whether writes to the COAST bit will be valid (BRAKE_MODE = 0x1), or if writes to the BRAKE bit will be valid (BRAKE_MODE = 0x0).

Regards,

Anthony Lodi

Hi Anthony,

I confirmed that the situation is the same whether BRAKE_MODE is 0 or 1. i.e. Coast functioning, but Brake not functioning.

It seems that the BRAKE_MODE pin controls whether the Brake hardware pin functions as a coast or brake. It does not change the functionality of the COAST SPI Register. And I can't confirm the same for the BRAKE SPI Register as it isn't working in the first place.

Hi Jerome, 

Are you using the GUI to write to the BRAKE bit? Or are you using a different interface for SPI writes and reads? I just want to ensure that you are not accidentally writing to a different address than the BRAKE bit. If you are writing and reading from the BRAKE bit, I am not sure why you are not seeing the motor braking. 

Regards,

Anthony Lodi

Hi Anthony,

I am using the GUI and I can confirm that I am writing a 0x02 to register address 0x09. I can read it back as well. It's weird that only coast is working...

Hi Jerome,

I may have to try this in lab to see if I can replicate your issue. Have you tried on more than 1 EVM?

Regards,

Anthony Lodi

Hi Anthony,

I only have one EVM but I have tried it with two different MTC8316Z (SPI Variant) ICs. It could be a soldering issue? I had a few issues that existed on the first IC I tried that were fixed in soldering the second one. But it's odd that only the brake register feature doesn't work for both ICs.

Hi Jerome,

It seems like if it was a soldering issue then none of the register settings could be written to. What GUI are you using? The online version?

Regards,

Anthony Lodi

Hi Anthony,

I am using the online GUI: https://dev.ti.com/gallery/view/InternalBLDC/MCT8316Z0REVM_GUI/ver/1.0.0/ 

I confirmed that multiple registers were being written to such as COAST, Buck voltage, Advance angle, Slew rate, and FGOUT during verification. I have the SPI lines probed with a logic analyzer to confirm these SPI transactions as well. This was done and confirmed on both chips. The problems that I was seeing with the first chip were commutation issues between digital and analog hall modes, and weird FGOUT waveforms. Everything else, the features seemed to make sense according to the datasheet.

Regards,

Jerome Villapando

Hi Jerome,

Sounds good, I will try this in lab and let you know if I can replicate the issue.

Regards,

Anthony Lodi

Thanks Anthony,

While you are at the lab can you double-check the initial SPI Register values on power up and on reset? This is what I got and there are some discrepancies with the datasheet:

This might be a clue to the overall problem.

Thanks again,

Jerome Villapando

Hi Jerome,

Thanks for sharing that information! That seems to give a clue as to what might be the problem. Could you probe the buck output as well as the VM voltage while powering up the device? The buck is used on the EVM to pull the nFAULT pin high, and if it fails to pull the nFAULT pin high enough by the time the VM voltage gets above the UVLO voltage, this can result in putting the device in an undesired state. It is possible that soldering issues on one or multiple of the buck related pins could result in the buck output not rising quick enough when powering on the device.

Regards,

Anthony Lodi

Hi Anthony, 

I confirmed that nFAULT is >2.2V before VM is even powered on. This is due to a internal pullup to 3.3V on the MSP430 side.

Hi Jerome, 

Some of our team members are currently out for travel 

But we will review your questions and aim to provide a response soon

Best Regards, 
Andrew 

Hi Jerome,

Thanks for the information, I did some testing in lab and found the default register settings to be the same as what you saw, with the exception of register 07h which was 0. Correlating this with the datasheet for the DRV8316-Q1, it looks like this corresponds with the default register settings for that device, with the exception of registers 02h and 09h showing the default is 0x0 in the DRV8316-Q1 datasheet. I am wondering if the MCT8316Z datasheet is showing incorrect default values, I will look at this in more detail to better understand it. 

I still haven't root caused the issue yet regarding the brake and coast bits, but I will continue to debug this issue.

Regards,

Anthony Lodi

Hi Anthony,

If you can confirm that both the brake and coast registers work that would be enough for me. Another thing I wanted to explore is if you were to set both brake and coast registers in a single write (just out of curiosity). 

Also, its weird that register 07h has a different value... I might try reading the registers again.

Hi Jerome,

I will try to verify this tomorrow, and will hopefully have the results by end of day or early next week.

Regards,

Anthony Lodi

Hi Jerome,

I worked on this in lab today, I ran into a few issues during testing that I am working through. I will resume testing either Monday or Tuesday.

Regards,

Anthony Lodi

Hi Jerome,

I spent some more time in lab today and was able to perform some testing, and was able to brake the motor by a SPI command. Interestingly I was having an opposite problem where the motor was almost always braking instead of coasting. The GUI is not completely functional/validated especially on the SPI communication, and I was finding that the SPI writes weren't always writing correctly, likely due to a bug in the firmware/GUI code. One of my coworkers that is more familiar with the EVM and GUI is planning on doing some testing as well, since he has been able to use the coast and brake bits successfully in the past. I will keep you updated on the debug. 

One thing to note is that the MCT device populated on the EVMs that I have in lab are older revision devices, so I plan on populating the current revision of the device on one of the EVMs to ensure that we have a 1 to 1 comparison.

Regards,

Anthony Lodi

Hi Anthony,

Thank you for going out of your way to do this.

Can you elaborate on "the motor was almost always braking instead of coasting"? Does that mean writing to the COAST register didn't always go through due to the SPI write issue?

Hi Jerome,

I was finding that writing to the coast bit would result in braking instead, and then when I would read all registers it was showing that the brake bit was set to 1, not the coast bit. I am not sure exactly what was going on, but it seems like the SPI writes were messing up. I wonder if you could try jumper wiring the SPI and writing the SPI registers through some different code instead of the GUI in case the GUI code is incorrect. One thing is you have to write to the unlock bits to allow for the SPI writes.

We will try to look into this more.

Regards,

Anthony Lodi

Hi Anthony,

This seems like a different issue from mine. I confirmed with a logic analyzer that the SPI reads and writes were what is expected. I can try with an external MCU shortly.

Regards,

Jerome

Hi Jerome,

I agree it seems like the problems I was seeing is different from what you were seeing. So you were able to confirm with a logic analyzer that the brake bit in the control register was successfully written to without seeing any change in the motor operation? We are ordering some newer MCT8316ZR-Q1 devices and will rerun the testing on our EVMs with those populated.

Regards,

Anthony Lodi

Hi Anthony,

Sorry for the late reply. The operation of my MCT8316 test setup has reverted to a weird state where it looks like the driver cannot spin the motor unless helped by hand to overcome the starting torque... I don't have much time to debug it right now, so do let me know if you can get it working on your end. This reassurance will help greatly.

Hi Jerome,

We have received a new MCT8316Z-Q1 unit which we are soldering onto an EVM. Will let you know the results of our testing once it is performed.

Regards,

Anthony Lodi

Hi Jerome,

I am waiting for a reply on the possible cause of the brake bit not working, I will set up a meeting with the team next week to discuss.

Regards,

Anthony Lodi

Hi Jerome,

I apologize for my failure to set up a meeting with the team this week, however I was able to make some progress over email. It seems like the brake bit may have been disabled, but I am working to confirm that with the team and understand the background on that change if in fact it was disabled. If the brake bit has been disabled, then the way to brake the device (instead of coasting) would be to set the BRAKE_MODE bit to 0 and use the brake pin to brake the motor. Coasting can still be achieved through the coast bit. I will keep you updated. 

Regards,

Anthony Lodi

Hi Anthony,

Thanks for all the updates. Please continue to keep us up to date with anything regarding the BRAKE SPI register. Thankfully, having brake for these drivers are not crucial for our application, but it gives us more flexibility in the future.

Regards,

Jerome

Hi Jerome,

I will definitely keep you up to date! 

Regards,

Anthony Lodi

Hi Anthony,

Any updates on this?

Regards,

Jerome

Hi Jerome,

There has been some progress in gathering some information, but nothing definitive yet. I sent a reminder to a coworker and am waiting for a response. Will provide an update by the end of this week as to where things are at. 

Regards,

Anthony Lodi

Hi Anthony,

Thanks for confirming this. Will the default SPI register values be updated as well?

Jerome

Hi Jerome, 

We will aim to give you a response next week 

Best Regards, 
Andrew 

Hi Anthony,

Thanks for all the work! Sorry for all the inconvenience.

Regards,

Jerome

Hi Jerome,

Your welcome! Glad I could help out. 

Regards,

Anthony Lodi