DRV8350H-EVM: MSP430 development board debug issues

Hi Cherry,

Thanks for posting your question to the e2e forum - 

I am looking into this and will follow up shortly.

• Just to clarify, are you saying that the 'reset is required to operate' is the DRV8350 device's ENABLE pin reset pulse for t_Reset duration?
  • or is this something coming from the MSP430 portion of the EVM? 

Best Regards,

Andrew

Hi Cherry,

I discussed this within the motor drives team, and we have re-assigned the thread to the MSP430 team.

I am reading above that the DRV device is able to operate the motor properly, after the reset pulse has been provided. 

So this seems more of an MSP430 operation question, which I am not too familiar with. 

Best Regards,

Andrew

Hi Andrew,

Thanks for your help and reply!

Expecting the updates!

Best Regards,

Cherry

Hi Cherry,

I do not think this is going to be a problem. We would suggest to connect the emulator when the board is powered off. And power up the emulator and the board when the connection is done. 

Best regards,

Cash Hao

Hi Cash,

Thanks for your reply and I have updated to the customer to check if it's helpful.

Thanks again!

Best Regards,

Cherry

Hi Cherry,

Quick question - is this other e2e post your customer?

https://e2e.ti.com/support/motor-drivers-group/motor-drivers/f/motor-drivers-forum/1043905/drv8350h-evm-drv8350h-msp430f5529-development-board-need-to-reset-or-power-off-but-quickly-repower-can-run-normally

It seems like they are the same question, but just wanted to confirm. 

There are some additional questions in there that I am looking into 

Thanks and Best Regards,
Andrew

Yes. that's the same question which I asked in the Chinese E2E and English E2E for quickly help!

Because I need the board to run  when the board is power up each time. But now it needs to reset or power-off but quickly power-up to run normally.

likely, the firmware runs into the sleep mode when the board is power-up. So need reset to run?

Hi Andrew,

Yes, it's the same question asked by my customer. And he is respond to this thread too. I believe you could communicate with him directly, that will be more clear and helpful!

Thanks!

Best Regards,

Cherry Zhou

Hi Scaler and Cherry,

Thanks for confirming both posts are about the same situation, so that I can cross-reference the information together into one story & help debug. 

• I'll help close the other thread for now, just so that we can keep the discussion in one place 

I am still thinking this is more of a setup issue on the side of the MSP430 device and code operation, since the DRV device is likely not undergoing an overtemperature fault during early device start-up. We can confirm this by checking the nFAULT LED (D10) and nFAULT waveform of the DRV device (it toggles logic low when there is a DRV-side fault, for any of the protections included in the DRV835x datasheet).

• if the nFAULT LED and pin never activate, then this points to the problem as being how the MSP430 device and code is handling these signals for LED D2 and D7. If that is the case, then we perhaps need to have someone from the MSP430 team review the code you are using just to make sure that we aren't accidentally reporting any false faults. 

• Like mentioned in the other two posts for this issue, the device you have is the 'H' version for DRV835x Hardware interface. 
  
  • Therefore, there shouldn't be any SPI-version reporting of fault diagnostic details like overtemperature, overcurrent, etc.. 
  • it will only tell you if there is a fault or not, and then toggle the one nFAULT pin and LED universally for all fault types. 

Best Regards,
Andrew

Hi Cash,

From the key info below, is it possible that Scaler is using a copy of the wrong EVM version's example code? 
I am not too familiar with the MSP430 operation itself, but I do not think that the EVM should be reporting these faults at all via the LEDs. 
I sent a request in the latest email response to ask if the DRV nFAULT pin can be probed, just to be certain.

Key info:

• Scaler mentioned that they are already connecting the emulator in a powered-off state, and then initializing power-up sequence after the board connection is complete. 
• They have to reset the MSP430 itself in order to make the system run normally, and that there is some LED2 and LED7 functionality happening to report different fault types
  • however, I am thinking that none of these LED2/LED7 signals should be happening since we aren't even using a SPI-enabled DRV device
  • the DRV8350H will only toggle nFAULT low for all fault conditions. No SPI commands or bit values are generated 
  • is there a way to confirm whether these lines of code are being executed, by adding breakpoints? 
  • does Scaler need to set 'sensoredTrapController.SPIvariant = FALSE' so that we make sure we skip this part of the code? 
    
    
    

From the other two ongoing threads, I have closed one of them so that we can keep the info centralized here for TI-side visibility. Here are the links:

• https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1043340/drv-8350-msp430f5529-online-debugging-is-normal-but-after-disconnect-ez-fet-emulator-and-repower-the-board-it-needs-to-reset-to-run
• https://e2e.ti.com/support/motor-drivers-group/motor-drivers/f/motor-drivers-forum/1043905/drv8350h-evm-drv8350h-msp430f5529-development-board-need-to-reset-or-power-off-but-quickly-repower-can-run-normally

Thanks and Best Regards,
Andrew

Hi Andrew,

I do not think that the example code is wrong. Because the MCU can run normally after a reset of a download. 

The question should be why the MCU need a reset after a download. It might related to the MCU code configuration is different form the emulator configuration or some other stuff. However, I still do not consider a reset on the MCU after download is an issue The code can run normally after the reset, right?

Best regards,

Cash Hao 

Hello,

Actually, I need the MCU to run  when the power is on, But now it need to reset.

Another thing is the motor can run normally during debugging.

Hi Cash,

Thanks for the response and advice/info on this.

So if the MCU reset is less of a functional issue, and more of a system-level preference from the customer/user, 

• Are there any other ways we can bypass this start-up command (since the advice above on adjusting the order of emulator connection and board power-up sequence didn't work)?

Best Regards,
Andrew

Hi,

So, If there is a method can solve this ? Waiting for your reply!

Thanks.

Hi Scaler, 

Sorry, I think a reset is necessary in this demo. 

May I ask why you can not have a reset in your application?

Best regards,

Cash Hao

Hi, 

Because this is a little smart section in my application ,it needs to run when the power is on. It is impossible  to click the RESET button during power on.

Thanks.

Hello, these several days I have tried and tried. I have found that when using the sensorless program. It did not have this problem. It do not need to reset.

why?

Hi Scaler,

What do you mean by using the sensorless program? Do you run with a different program?

So, some thoughts from my side.

1. The clock system issue. Are there any crystal used in your board? A crystal failure can cause the issue. If not, check the DCO clock setting in your software.

2. Programmer issue. Are you using the MSP-FET or MSP-GANG to download the problem to your board? A third party programmer might also cause this issue.

Best regards,

Cash Hao

Thank you for your answers.

may you good all day!

Yeah, because of needing RESET when running the sensored program. So I have tried the sensorless control program. It did not  need to RESET to run.

answer your question 1 and 2.

1.I have used crystal in my board. the DCO clock setting keep unchanged compared with the TI drv8350H _EVM sensored control algorithm.

2.I have use the LP-MSP430FR2476 Development kit .and used the three PIN of SBWTDIO /SBWTCK /GND to download the firmware to my board.

Waiting for your further answer.

Best regards,

Scaler_cao