[work notes] the problem of high leakage current in standby mode of dw7888 motor driver chip

Find the problem

The customer reported that the leakage current of our hardware is very high , But unplug the battery and then power it on （ Still shut down ） It will return to 16~20uA about . This surprised me too , Because I have tested it myself , Leakage current only MCU Sleep current  16~20uA about  （ Contains some electronic components ）, Far below the project requirements <100uA.

Watch the customer's recurrence steps , It is found that every time the customer shuts down , Will trigger some functions of the device through touch , And my test is after the boot , When the upper computer runs normally, it will be shut down directly （ The motor is not driven to rotate ）.

To analyze problems

The most intuitive function of touch trigger is to make the motor rotate , Therefore, it is highly suspected that it is related to the function of the motor drive part , By disconnecting the upper computer , Directly control the equipment to turn the motor through the serial port , Then turn it off , Sure enough, the problem reappears , Leakage current is 380uA about . When problems arise , The battery must be unplugged and then powered on again , The current will fall to the normal range （20uA about ）.

Motor drive IC Yes 6 star , They are equally distributed in A、B On two auxiliary boards , Unplug the motor drive cable of the auxiliary board , The current drops directly to 200uA about , This is true of repeated tests , It doesn't have much to do with the motor . So confirm with motor drive IC of , Measure the control signal of the control chip through the oscilloscope , Confirm that the software control logic is correct , At this time, it is found that the power supply of the motor chip is not controlled , Directly powered by battery .

Motor drive IC Model is DW7888, We found the specifications , Standby current <2uA, So even if the power is not turned off , In standby mode , The leakage current is not so large .

Then recall the problem recurrence process , After power on, the default mode is standby mode , Why a drive motor , Then enter standby mode , There will be problems ？

This is not consistent with the chip specification ？ After communicating with our hardware engineers , Let me put the chip into braking mode when something goes wrong , Then enter standby mode . It is thought that the specification has written that the braking mode can release the motor energy , Feel the chance to , It's easy to use a flying wire 3.3V, Drive one of the motors at the same time IC Two input signals of touch （FI\BI Set high level ）, A miracle happened , The current actually dropped 60uA about , Operate all motors in this way one time in turn , The current finally drops to 20uA The level of , Explain each drive IC The leakage current is 60uA about .

I am very excited to pass MCU To simulate this operation , The results were surprising , It didn't work , Take out an oscilloscope to measure , It was found that the brake signal was indeed given , puzzled （ The reasons are explained below ）.

Finally, call the supplier , The supplier took a long time to reply that the standby current of the chip itself was   50uA~60uA about , But this reply can not explain the phenomenon we measured , Just ask him to contact the engineer of the original chip factory to communicate about this matter .

solve the problem

The whole situation has been re communicated with the original manufacturer , Finally, they confirmed that this was a design defect of the chip , In view of our new discovery , He was also very surprised , I hope we can send them a set of platforms , The analysis reason .

The final answer is FI、BI The interval between two signals pulling down at the same time should be very short , And our two signals have lowered the interval 900ns, They 8M Of MCU At the same time, set the pull down （ Affected by the accuracy of oscilloscope , There is no time difference ）, Can solve this problem .

See light suddenly , Why didn't we think of it , When we were testing, we were going to DW7888 The input signal flying wires are screwed together , And then touch 3.3V Only high level , To enter the braking mode , Voltage is transmitted to two signals at the same time . and MCU Is the sequential execution of code , So there will be priorities , There is always a gap . It's just us  MCU The main frequency is 72M There is no reason to compare with their original factory 8M Of MCU Also slow , Go straight to code analysis , See if there is room for optimization . 

The code we simulated , Consider portability and configurability , An array is used to store each configured in the configuration file GPIO, Therefore, the implementation is as follows ：

The measured waveform is as follows , The interval between two control signals is about 900ns：

The code above is pin by pin control , The time interval between the two pin control signals is 900ns, You can remove loop statements and set multiple register bits at the same time , To shorten the time interval of the control signal . Therefore, modify the code as follows ：

The measured waveform is as follows , In the same group GPIO Almost at the same time （ The accuracy of oscilloscope is limited ）：

It is found that one of them still exists 60uA electric current , Check the schematic diagram and find out the FI\BI The control feet are respectively at GPIOA and GPIOB Group , The measured waveforms are as follows （500ns）：

because GPIOA、GPIOB The two groups are pulled down by calling functions respectively , Considering the consumption of function on and off the stack , Direct operation of registers ：

The measured waveforms are as follows , Interval about 124ns （ Here we can intuitively show how much the stack in and stack out consumption of calling ordinary functions is ,72MHz The main frequency of , slow 4 More than double ）：

The measured results are passed ,16uA：

Final patch

The above is only engineering verification , Practical applications also need to consider code maintainability and stability , If there is a need for clear comments , And the need to consider the impact of interruptions .

--- configuration.h	2020-12-10 11:28:07.000000000 +0800
+++ configuration.h	2020-12-10 11:23:40.000000000 +0800
@@ -169,12 +169,35 @@
 #define MOTOR_FI_RFRONT_PWM_CHANNEL				8		
 #define MOTOR_BI_LBACK_PWM_CHANNEL					9				//  Left rear motor 
 #define MOTOR_FI_LBACK_PWM_CHANNEL					10		
 #define MOTOR_BI_RBACK_PWM_CHANNEL					11				//  Right rear motor 
 #define MOTOR_FI_RBACK_PWM_CHANNEL					12
 
+// ------------------------------------  Be careful (lmx:20201210) -----------------------------------
+
+//  Repair  DW7888  Chip defect ( It should be noted that this related code only applies to  DW7888  Driver chip ): 
+// 1. When the motor is driven, it will enter the standby mode ,  Every chip will exist  60uA  Left and right leakage current ,  The power supply of these chips is not controlled 
+// 2. The effective repair method is to enter the braking mode first ,  Then enter standby mode ,  The time for two input signals to be pulled down at the same time must be less than  500ns
+// 3. Due to the current hardware design, there is a driver chip used respectively  GPIOA-15\GPIOB-3  Two sets of pins ,  Therefore, it is not possible to set at the same time 
+// 4. The actual measurement can shorten two groups by directly operating registers  GPIO  Control time interval (124ns):
+// unsigned int groupa_allpin = FIX_DW7888_CHIP_BUG_GPIO_PIN_1;
+// unsigned int groupb_allpin = FIX_DW7888_CHIP_BUG_GPIO_PIN_2;
+// GPIO_BOP(FIX_DW7888_CHIP_BUG_GPIO_GROUP_1) = groupa_allpin;
+// GPIO_BOP(FIX_DW7888_CHIP_BUG_GPIO_GROUP_2) = groupb_allpin;
+// delay_1ms(100U);
+// disable all interrupt code
+// GPIO_BC(FIX_DW7888_CHIP_BUG_GPIO_GROUP_1) = groupa_allpin;
+// GPIO_BC(FIX_DW7888_CHIP_BUG_GPIO_GROUP_2) = groupb_allpin;
+// enable all interrupt code
+
+#define FIX_DW7888_CHIP_BUG_GPIO_GROUP_1			GPIOA
+#define FIX_DW7888_CHIP_BUG_GPIO_PIN_1				(GPIO_PIN_9 | GPIO_PIN_8 | GPIO_PIN_15 | GPIO_PIN_10 | GPIO_PIN_11)
+#define FIX_DW7888_CHIP_BUG_GPIO_GROUP_2			GPIOB
+#define FIX_DW7888_CHIP_BUG_GPIO_PIN_2				(GPIO_PIN_13 | GPIO_PIN_12 | GPIO_PIN_15 | GPIO_PIN_14 | GPIO_PIN_4 | GPIO_PIN_5 | GPIO_PIN_3)
+// ------------------------------------  Be careful (lmx:20201210) -----------------------------------
+
 // Action  Timing module 
 #define CFG_ACTION_TIMER							TIMER13
 #define CFG_ACTION_TIMER_RCU_CLOCK					RCU_TIMER13
 #define CFG_ACTION_TIMER_IRQ_NUMBER				TIMER13_IRQn
 #define CFG_ACTION_TIMER_IRQ_FUNCTION				TIMER13_IRQHandler
 

--- Interface\common.c	2020-12-10 11:28:40.000000000 +0800
+++ Interface\common.c	2020-12-10 11:26:15.000000000 +0800
@@ -18,12 +18,43 @@
 #include "common.h"
 #include "sensor_infra_red.h"
 #include "motor_control.h"
 #include "action_process.h"
 #include "function_switch.h"
 
+// ------------------------------------  Be careful (lmx:20201210) -----------------------------------
+//  Repair  DW7888  Chip defect ( It should be noted that this related code only applies to  DW7888  Driver chip ): 
+// 1. When the motor is driven, it will enter the standby mode ,  Every chip will exist  60uA  Left and right leakage current ,  The power supply of these chips is not controlled 
+// 2. The effective repair method is to enter the braking mode first ,  Then enter standby mode ,  The time for two input signals to be pulled down at the same time must be less than  500ns
+// 3. Due to the current hardware design, there is a driver chip used respectively  GPIOA-15\GPIOB-3  Two sets of pins ,  Therefore, it is not possible to set at the same time 
+// 4. The actual measurement can shorten two groups by directly operating registers  GPIO  Control time interval (124ns):
+// ------------------------------------  Be careful (lmx:20201210) -----------------------------------
+static void dw7888_low_power_mode()
+{
+	unsigned int groupa_allpin = FIX_DW7888_CHIP_BUG_GPIO_PIN_1;
+	unsigned int groupb_allpin = FIX_DW7888_CHIP_BUG_GPIO_PIN_2;
+
+	//  Braking mode 
+	GPIO_BOP(FIX_DW7888_CHIP_BUG_GPIO_GROUP_1) = groupa_allpin;
+	GPIO_BOP(FIX_DW7888_CHIP_BUG_GPIO_GROUP_2) = groupb_allpin;
+	delay_1ms(100U);
+
+	//  Standby mode 
+	__disable_irq();
+	GPIO_BC(FIX_DW7888_CHIP_BUG_GPIO_GROUP_1) = groupa_allpin;
+	GPIO_BC(FIX_DW7888_CHIP_BUG_GPIO_GROUP_2) = groupb_allpin;
+	__enable_irq();
+	
+	return ;
+}
+
+static void common_fix_chip_bug_release()
+{
+	dw7888_low_power_mode();
+}
+
 static void common_periph_clock_init()
 {
 	//  System tick clock initialization 
 	systick_config();
 	
 	//  Enable each common clock 
@@ -85,14 +116,14 @@
 	simple_sensor_release();
 	adc_control_release();
 	led_control_release();
 	master_transfer_release();
 	power_manager_release();
 	time_base_release();
+	common_fix_chip_bug_release();
 	common_periph_clock_release();
-	
 	return ;
 }
 
 //  Enter upgrade mode ( The essence is to jump to  boot )
 void common_enter_update_mode(void)
 {

The problem summary

1. When you want to test low power consumption after writing the program , Should be fully functional after the run , Then turn off the machine to check the leakage current .

2. Later, we found that in the chip acknowledgment DW7888 The standby current in the specification is changed to <50uA, That is, problems can be found at the beginning of model selection , But our hardware engineers are not careful enough （ Despite his signature ）, This also confirms that the supplier actually knows that there is such a problem , The original factory didn't know that there was such a solution .

3. Like multiple signals need to be triggered at the same time , Using manual testing can pass , however MCU The simulation failed , You need to consider first GPIO The time between , because MCU The code is executed serially , Unlike FPGA Multiple code blocks can be triggered to execute simultaneously by one clock . So simple , Let me be ignored , Ignored , Ignored , alas ...