7798 views|28 replies

9720

Posts

24

Resources
The OP
 

Cause of unstable current when STEVAL-IDB007V1 does not process DIO0~DIO3 [Copy link]

 
 During the development of the challenge, I encountered a problem. If the external IO is not processed when BlueNRG-1 enters sleep mode, the current will fluctuate unstably. When it is high, it can reach several milliamperes, and when it is low, it can be around 9uA. Under normal circumstances, the total current of BlueNRG-1 after sleep plus the standby current of the sensor should be below 10uA. This is normal. I have encountered similar problems in other microcontrollers before because the unused I/O of the microcontroller was not processed. This time I began to suspect that it was also a problem with the microcontroller I/O. Later, after analysis, I found that the problem occurred in LSM6DS3 instead of BlueNRG-1. ont=微软雅黑]The testing process was very painful and intermittent. It took me many days to find the cause.
In order to find the problem with the STEVAL-IDB007V1 board, I even doubted several times whether I was too old and not suitable for this job.
But fortunately, no matter how many detours I took and how much time I spent, I finally found this part of the problem.
[align=l eft]During the test, many "hard injuries" were left on STEVAL-IDB007V1, including cutting and punching (because some of the traces on the 4-layer board are on the inner layer, it is necessary to punch to cut the traces)
Below is the record I made when I was looking for the cause
It took me many days to find the cause, and my brain was in a mess at the time. After sorting it out, some places are still very messy
I started by using the following topology to measure the current of the development board
When LSM6DS3 and LPS25HB are powered off and BlueNRG-1 is in sleep mode
the current can reach several milliamps when it is high and about 9uA when it is low
After analysis, it was determined that the four pins DIO0~DIO3 needed to be processed (after finding the problem, the wires that were cut on the board were restored and it was found that DIO1 did not need to be processed. DIO1 was at a high level when not processed). Pulling up or down can stabilize the current
The following is the current change when other I/Os are suspended and the specified I/O is grounded
In the schematic diagram, we can see that DIO0~DIO3 are mainly connected to LSM6DS3, corresponding to SPI's CS, SCLK, SDI,In addition to DIO0~DIO3, we can see that DIO12 of BlueNRG-1 is also directly connected to LSM6DS3. If the problem lies with LSM6DS3, why doesn't DIO12 need to be processed?
Find the power supply route of the sensor by analyzing the Gerbre file
Disconnect the sensor's power supply from VBLUE by cutting the trace on the PCB
The current of the VBLUE network still changes, the highest is about 600uA, and the lowest is still 9uA
Compared with the change of the sensor power supply below, it is better
The total current of LPS25HB and LSM6DS3 in PowerDown mode should be about 6.5uA. After cutting off the power supply of the sensor, the idle current is still about 9uA. Why doesn't the current drop?
Measure the sensor power supply (the network of the disconnected sensor division is named VBLUE_SENSOR), there will be a voltage of about 2.5V (this value is constantly changing), where does this power supply come from?
Measure DIO12 as 0V, measure DIO4 and DIO5 (SCL and SDA of LPS25HB) as VBLUE_SENSOR voltage
Measure DIO0, DIO2 and DIO3 as 0V, measure DIO1 as VBLUE_SENSOR voltage
Check again and see that the disconnected VBLUE_SNEOSR is still connected to U10
In the schematic diagram, SPI is also connected to STG3692 through a 0 ohm resistor
ont]
After analysis, this should not be the reason, because there will be a 2.5V voltage when the VBLUE_SENSOR power supply is disconnected
The main suspects are DIO1, DIO4 and DIO5. There is no place to provide power for these three I/Os
Later, when checking the physical picture, the corresponding resistors were not welded
It is certain that the problem has nothing to do with STG3692
Looking at the schematic again, I found a suspicious object PUSH2. I2C2_DATA is connected to VBLUE here through a pull-up resistor. I measured the voltage across R54, one end is 3.3V and the other end is 2.xV
Because the official schematic cannot be retrieved by network label, I moved the BlueNRG-1, BlueNRG-2 development kits en.DM00298232.pdf document to retrieve the network label
Unfortunately, Figure 29 in the manual:The STEVAL-IDB007V1 buttons and LEDs are provided in the form of pictures and cannot be retrieved by network label, so they are often missed.
The next step is to disconnect R54 and VBLUE, and then measure the voltage. After disconnection, both ends of R54 are 2.xV. Doesn't the electricity come through R54?
Press and hold the reset button on the development board and measure the voltages of DIO1, DIO4, DIO5 and VBLUE_SENSOR. They all become 0V. Release the button and power on and the voltages return to 2.xV
Open the oscilloscope to measure the voltage of DIO4 and DIO5, only to see that the voltage decreases with the increase of current, but I still can't find the reason.
Directly power VBLUE1 and pull RESETN to VDD with a current of 600 uA
Connect VBLUE_SENSOR to GND, the idle current is about 47uA
When DIO05 and DIO04 are short-circuited with GND respectively, the current is 126.7uA. When DIO5 and DIO4 are connected to GND at the same time, the current is 75uA
When DIO1 is short-circuited with GND, the current is 249uA
Current situation when VBLUE_SENSOR is connected to GND, VBLUE and idle
When VBLUE_SENSOR is connected to GND, the current is about 42uA. After waking up and then sleeping, the current does not change.
If the current of the sensor is basically obtained through the VBLUE_SENSOR network, the current when VBLUE_SENSOR is grounded is 42uA. When VBLUE_SENSOR is disconnected, the current that the sensor can obtain from the VBLUE_SENSOR network will not exceed 42uA.
GPIO1 is connected to GND, the current is about 248uA, the current will increase after waking up and then sleeping
When GPIO1 is connected to GND, the current is 248uA. If you do not disconnect GPIO1 from GND and connect BLUE_SENSOR to GND, the current will drop to 42uA
When GPIO1 is connected to GND, the voltage of VBLUE_SENSOR is 1.5V. If you connect DIO4 or DIO5 to GND, the voltage of VBLUE_SENSOR is 0.5V
Finally, when I used a multimeter to measure DIO11, I accidentally short-circuited it with pin5 of U10 and found that the current jumped to 600uA
Current when DIO11 and pin5 of U10 are short-circuited
Further testing found that if U10's pin4 (BlueNRG-1's DIO11) is connected to GND, the current is 42uA, and if pin5 is connected to GND, the current remains unchanged at 9uA. If pin4 and pin5 are connected to GND at the same time, the current is 42uA
But as long as the connection to GND is disconnected and only pin4 and pin5 are shorted, the current will reach 600uA
If VBLUE_SENSOR is connected to GND, the current is 42uA, and then short-circuiting pin4 and pin5 of U10 does not change the current
Using a multimeter to measure the current from VBLUE_SENSOR to GND is 43uA, the overall current consumption of VBLUE is 45.75uA, and the current from U10 pin4 to GND is 48uA, the overall current consumption of VBLUE is 43.95
Use a multimeter to test the voltage of pin4 of U10, which is higher than the voltage of VBLUE_SENSOR
Short-circuit VBLUE_SENSOR and GND at VBLUE_SENSOR
Later I found the description of DIO11 in the BlueNRG-1 data sheet.
DIO11 is in uplink mode in sleep mode.
The pull-up resistor is 81KhOM corresponding to 40uA
Looking at the data sheet of ST2378E, we can see that each of its I/Os is connected to VL through a 9K pull-up resistor
YaHei]This explains how the voltage of VBLUE_SENSOR comes from.
The current flows from VDD of BlueNRG-1 to DIO11 through the 81K pull-up resistor, and then flows to VBLUE_SENSOR through the 9K pull-up resistor of ST2378E.
Although the pull-up resistor of IO11 can be disabled by code, the pull-up function will be restored after entering low power mode. /** Init Structure */ GPIO_StructInit(&GPIO_InitStructure); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_11;
GPIO_InitStructure.GPIO_Mode = GPIO_Input;
GPIO_InitStructure.GPIO_Pull = DISABLE;
GPIO_InitStructure.GPIO_HighPwr = DISABLE;
GPIO_Init(&GPIO_InitStructure);
After disconnecting U10's VDD, the current drops to normal, with an average current of 752nA, which should be the sleep current of BlueNRG-1 when no sensor is connected
Measuring the current of VBLUE and VBLUE_SENSOR at the same time, we can see that the current is mainly consumed by the VBLUE_SENSOR power network
-
There are two sensors on the power network of VBLUE_SENSOR, namely LSM6DS3 and LPS25HB. Judging from the configuration of the pins, the current should be consumed by LSM6DS3, because LPS25HB is only connected to the I2C pin
In order to verify this judgment, it is necessary to disconnect the power supplies of LSM6DS3 and LPS25HB. From the GERBER file, it can be seen that the power supplies of LSM6DS3 and LPS25HB are connected through the middle GND (green) and PWR (cyan) layers
If you want to disconnect, you need to punch a hole at the specified position to destroy the inner layer connection
The following is the PCB board after punching
The current of VBLUE and VBLUE_SENSOR after removing LSM6DS3. You can see that the current of the two power supply networks has dropped.
The problem of unstable current of STEVAL-IDB007V1 when BlueNRG-1 is in sleep state has been found. The problem lies in LSM6DS3.
Why does LSM6DS3 have this problem? Because pin2 and pin3 of LSM6DS3 on STEVAL-IDB007V1 are directly connected to ground. I am going to buy a LSM6DS3 development board online for testing, hoping to find the reason. Another question is that when VBLUE_SENSOR is powered by DIO11, the maximum current it can get from DIO11 is about 40uA, but why can the current consumption from VBLUE reach 600uA?
There are two sensors on the power network of VBLUE_SENSOR, namely LSM6DS3 and LPS25HB. Judging from the configuration of the pins, the current should be consumed by LSM6DS3, because LPS25HB is only connected to the I2C pin
In order to verify this judgment, it is necessary to disconnect the power supplies of LSM6DS3 and LPS25HB. From the GERBER file, it can be seen that the power supplies of LSM6DS3 and LPS25HB are connected through the middle GND (green) and PWR (cyan) layers
If you want to disconnect, you need to punch a hole at the specified position to destroy the inner layer connection
The following is the PCB board after punching
The current of VBLUE and VBLUE_SENSOR after removing LSM6DS3. You can see that the current of the two power supply networks has dropped.
The problem of unstable current of STEVAL-IDB007V1 when BlueNRG-1 is in sleep state has been found. The problem lies in LSM6DS3.
Why does LSM6DS3 have this problem? Because pin2 and pin3 of LSM6DS3 on STEVAL-IDB007V1 are directly connected to ground. I am going to buy a LSM6DS3 development board online for testing, hoping to find the reason. Another question is that when VBLUE_SENSOR is powered by DIO11, the maximum current it can get from DIO11 is about 40uA, but why can the current consumption from VBLUE reach 600uA?
There are two sensors on the power network of VBLUE_SENSOR, namely LSM6DS3 and LPS25HB. Judging from the configuration of the pins, the current should be consumed by LSM6DS3, because LPS25HB is only connected to the I2C pin
In order to verify this judgment, it is necessary to disconnect the power supplies of LSM6DS3 and LPS25HB. From the GERBER file, it can be seen that the power supplies of LSM6DS3 and LPS25HB are connected through the middle GND (green) and PWR (cyan) layers
If you want to disconnect, you need to punch a hole at the specified position to destroy the inner layer connection
The following is the PCB board after punching
The current of VBLUE and VBLUE_SENSOR after removing LSM6DS3. You can see that the current of the two power supply networks has dropped.
The problem of unstable current of STEVAL-IDB007V1 when BlueNRG-1 is in sleep state has been found. The problem lies in LSM6DS3.
Why does LSM6DS3 have this problem? Because pin2 and pin3 of LSM6DS3 on STEVAL-IDB007V1 are directly connected to ground. I am going to buy a LSM6DS3 development board online for testing, hoping to find the reason. Another question is that when VBLUE_SENSOR is powered by DIO11, the maximum current it can get from DIO11 is about 40uA, but why can the current consumption from VBLUE reach 600uA?

This post is from ST - Low Power RF

Latest reply

OK, thanks for the recent help. We have modified a version of the circuit board, and now it is fixed. The power consumption is about 6ua when in sleep mode and without broadcasting. If it happens once per second, it will be around 16ua. We will ask ST about the automatic IO configuration after broadcast wakeup and see if they have any reply. We will post it later. Many thanks   Details Published on 2019-8-23 17:04
Personal signature虾扯蛋,蛋扯虾,虾扯蛋扯虾
 
 

664

Posts

104

Resources
2
 
This post was last edited by gs001588 on 2018-3-16 12:14 The moderator littleshrimp has done too much research and is very thorough. At the time, I only thought that SPI_CS must be connected high, and I was worried that if the chip select was valid, the SPI output line of the sensor would have data. I didn't think much about the other things, and connected SPI_CLK, SPI_IN, and SPI_OUT all low. Maybe SPI_IN doesn't need to be processed. I noticed the internal pull-up of IO12, but I didn't check what level of INT1 of LSM6DS3 was valid, and whether it was turned on. I thought that as long as the sensor was turned off and no interrupt was generated, it would not affect this pin. Now I think it's really wrong, and I need to learn from the moderator.
This post is from ST - Low Power RF
 
 
 

5

Posts

0

Resources
3
 
The OP is awesome. What software is that to display the waveform? It looks good.
This post is from ST - Low Power RF

Comments

Simplicity Studio, with silabs single-chip development board, can realize current measurement. The main control is realized by STM32F103 single-chip computer. If you are interested, you can also DIY one yourself.  Details Published on 2018-3-19 12:52
 
 
 

9720

Posts

24

Resources
4
 
suwei337008 posted on 2018-3-16 15:19 The OP is awesome. What software is that to display the waveform? It looks good
Simplicity Studio, with the silabs microcontroller development board, can realize current measurement. The main control is implemented using the STM32F103 microcontroller. If you are interested, you can also DIY one yourself
This post is from ST - Low Power RF
Personal signature虾扯蛋,蛋扯虾,虾扯蛋扯虾
 
 
 

29

Posts

0

Resources
5
 

Awesome OP, I have a question for you. Has anyone done an in-depth study on the pin configuration after wake-up?

My device uses IO1 IO2 1O3 to control a common anode three-color light, broadcasting once per second.

I read that broadcasting can also wake up the microcontroller

In actual tests, the light flashes faintly every time it is woken up, and the momentary low level is also seen with an oscilloscope. If there is no other event after the program goes to sleep and wakes up, I will not operate the IO port.

I feel this phenomenon is caused by the microcontroller taking over IO after waking up.

I later changed to a common cathode LED lamp and the flickering problem disappeared.

But I don't know the specific reason

This post is from ST - Low Power RF

Comments

Do all three pins have a momentary low level or do some of them have a momentary low level?  Details Published on 2019-8-12 12:39
 
 
 

9720

Posts

24

Resources
6
 
baixiukai posted on 2019-8-12 11:55 Awesome, I have a question for you. Has anyone done an in-depth study on the pin configuration after wake-up? My device uses IO1 IO2 1O3 to control a common...
Do all three pins have a momentary low level or do some of them have it?
This post is from ST - Low Power RF

Comments

Now I test it and it is like this. If I configure IO0-IO10 to a high level after sleep, it will be pulled down instantly after waking up. I put a picture. This is the situation of these pins. Broadcast once per second, and you will find that the pin is pulled down instantly for 1 second to return to high.  Details Published on 2019-8-12 14:12
Now I test it and it is like this. If I configure IO0-IO10 to a high level after sleep, it will be pulled down instantly after waking up. I put a picture. This is the situation of these pins. Broadcast once per second, and you will find that the pin is pulled down instantly for 1 second to return to high.  Details Published on 2019-8-12 14:06
 
 
 

29

Posts

0

Resources
7
 
littleshrimp posted on 2019-8-12 12:39 Are all three pins at a momentary low level or are they only on individual pins?

Now test it, it is like this, IO0-IO10,

If I configure it to a high level after sleep, it will be pulled down instantly after waking up.

I put a picture of these pins.

If the broadcast is broadcast once per second, you will find that the pin is pulled down momentarily for one second and then returns to a high level.

BSZW.png (141.68 KB, downloads: 0)

BSZW.png
This post is from ST - Low Power RF
 
 
 

29

Posts

0

Resources
8
 
littleshrimp posted on 2019-8-12 12:39 Are all three pins at a momentary low level or are they only on individual pins?

This is the phenomenon that occurs when the following few devices are configured to high level after sleep

This post is from ST - Low Power RF

Comments

I used the official BLE_Beacon routine to do the experiment you mentioned. The broadcast interval was 1S. I first initialized the DIO6 output mode, pulled it up, and output a high level. Then I added a code to flip DIO6 after the main loop "BlueNRG_Sleep(SLEEPMODE_NOTIMER, 0, 0);"  Details Published on 2019-8-12 16:28
 
 
 

9720

Posts

24

Resources
9
 
baixiukai posted on 2019-8-12 14:12 This is the phenomenon that occurs when the high level is configured after the sleep state

I used the official BLE_Beacon example to do the experiment you mentioned.

The broadcast interval is 1S. Initialize the DIO6 output mode first, pull up, and output high level

Then add a code to flip DIO6 after the main loop "BlueNRG_Sleep(SLEEPMODE_NOTIMER, 0, 0);"

Using an oscilloscope, you can see that it flips every 1 second

Then comment out the flip code of the main loop and use an oscilloscope to observe that DIO6 is always at a high level without any jumps.

Test Engineering

BLE_Beacon.rar (32.65 KB, downloads: 2)

This post is from ST - Low Power RF

Comments

Thank you very much. I am very helpless. Is it related to the configuration? I have blocked the main program. [attachimg]427681[/attachimg] The result is that the pin status is like this [attachimg]427679[/attachimg] The broadcast interval is once every 1 second, and the pin configuration [attachimg  Details Published on 2019-8-12 17:47
Personal signature虾扯蛋,蛋扯虾,虾扯蛋扯虾
 
 
 

29

Posts

0

Resources
10
 
This post was last edited by baixiukai on 2019-8-13 10:44

The last reply had a formatting problem and was too long, so I deleted it.

image.png (95.49 KB, downloads: 0)

image.png

image.png (1.12 MB, downloads: 0)

image.png

image.png (57.81 KB, downloads: 0)

image.png

image.png (78.89 KB, downloads: 0)

image.png

image.png (70.73 KB, downloads: 0)

image.png
This post is from ST - Low Power RF

Comments

From your oscilloscope, it looks like a high level pulse. You configured the LED to pull up.  Details Published on 2019-8-13 09:43
 
 
 

9720

Posts

24

Resources
11
 
baixiukai posted on 2019-8-12 17:47 littleshrimp posted on 2019-8-12 16:28 I used the official BLE_Beacon routine to do the experiment you mentioned. The broadcast interval is 1S. First...

From your oscilloscope, it looks like a high level pulse. You configured the LED to pull up.

This post is from ST - Low Power RF

Comments

In actual testing, this high-level signal lasts for about 2.7ms.  Details Published on 2019-8-13 10:45
Personal signature虾扯蛋,蛋扯虾,虾扯蛋扯虾
 
 
 

29

Posts

0

Resources
12
 
littleshrimp posted on 2019-8-13 09:43 From your oscilloscope, it looks like a high-level pulse. You configured the LED to be pulled up

In actual testing, this high-level signal lasts for about 2.7ms.

This post is from ST - Low Power RF

Comments

Remove GPIO_Pull = ENABLE and test a GPIO that is not connected to other circuits.  Details Published on 2019-8-13 10:48
 
 
 

9720

Posts

24

Resources
13
 
baixiukai posted on 2019-8-13 10:45 In actual testing, this high-level signal lasts for about 2.7ms.

Remove GPIO_Pull = ENABLE and test a GPIO that is not connected to other circuits.

This post is from ST - Low Power RF
Personal signature虾扯蛋,蛋扯虾,虾扯蛋扯虾
 
 
 

29

Posts

0

Resources
14
 
littleshrimp posted on 2019-8-13 10:48 Remove GPIO_Pull = ENABLE and test a GPIO that is not connected to other circuits.

The moderator thanks you for your help these two days. Can you add me on WeChat? 15215326245. Recently, I have been working on a project and have encountered many power consumption and abnormal problems. I feel that the data I read is similar to the configuration, but the actual phenomenon is really hard to accept .

This post is from ST - Low Power RF
 
 
 

29

Posts

0

Resources
15
 

I also tried leaving other pins floating, and the level did jump, and the broadcast jumped. The pin status of the beacon routine you sent should be wrong. After sleep, IO6 cannot maintain the original high or low level normally. It is in high impedance state after sleep.

This post is from ST - Low Power RF

Comments

At first, I wanted to use external resistors for pull-up and pull-down. Later, when I didn't use external resistors, the problem you encountered did not occur, so I didn't bother to test it. If you don't connect resistors, your problem will not occur. This problem should have nothing to do with the resistors. Otherwise, you can use BLE_Beac  Details Published on 2019-8-19 21:08
 
 
 

9720

Posts

24

Resources
16
 
baixiukai posted on 2019-8-19 14:20 I also tried leaving the other pins floating, and the level did jump, and the broadcast jumped. The pin status of the beacon routine you sent should be wrong, and IO6 cannot function normally after sleep...

At first I wanted to use external resistors for pull-up and pull-down

Later, when the external resistor was not used, the problem you encountered did not occur, so I did not test it.

If you don't connect the resistor, your problem will not occur. This problem should have nothing to do with the resistor.

How about you modify the BLE_Beacon example to reproduce the problem you encountered, and then I will test it according to your method to help you find the cause?

This post is from ST - Low Power RF

Comments

I used the development board to test it out like this [attachimg]428730[/attachimg] Modified using the Beacon routine. [attachimg]428731[/attachimg] Add IO configuration code [attachimg]428732[/attachimg] Modify the broadcast interval [attachimg]428733[/attac  Details Published on 2019-8-20 11:55
I used the development board to test it out like this [attachimg]428730[/attachimg] Modified using the Beacon routine. [attachimg]428731[/attachimg] Add IO configuration code [attachimg]428732[/attachimg] Modify the broadcast interval [attachimg]428733[/attac  Details Published on 2019-8-20 11:52
Personal signature虾扯蛋,蛋扯虾,虾扯蛋扯虾
 
 
 

29

Posts

0

Resources
17
 
littleshrimp posted on 2019-8-19 21:08 At first I wanted to use external resistors for pull-up and pull-down. Later, when I didn't use external resistors, the problem you encountered did not occur, so I didn't bother to test it...

I used the development board to test it.

was modified using the Beacon example.

Add IO configuration code

Modify the broadcast interval

Add test code to the main program

The actual waveform after zooming in is this. It feels weird.

BLE_Beacon_b.zip

3.08 MB, downloads: 1

This post is from ST - Low Power RF

Comments

I tried your code. There is a sentence "GPIO_ToggleBits(GPIO_Pin_6);" in the while. Comment it out and DIO6 will always be at low level.  Details Published on 2019-8-20 16:54
 
 
 

29

Posts

0

Resources
18
 
littleshrimp posted on 2019-8-19 21:08 At first I wanted to use external resistors for pull-up and pull-down. Later, when I didn't use external resistors, the problem you encountered did not occur, so I didn't bother to test it...

Test IO configuration

Modify the broadcast interval

Main function configuration

The actual test of the pin fluctuation once per second is the result of my test with the development board.

This post is from ST - Low Power RF
 
 
 

869

Posts

0

Resources
19
 
I also tried leaving the other pins floating, and the level did jump, and the broadcast jumped
This post is from ST - Low Power RF

Comments

Have you tried it? I seem to have found a pattern, that is, IO0 to IO8 and IO14 are configured to output low level before sleep, and they will not jump after broadcast wake-up. IO9-IO11 have internal pull-ups, so they must be configured to high level before sleep, and jump after wake-up. But I have not found the exact instructions.  Details Published on 2019-8-20 13:20
 
 
 

29

Posts

0

Resources
20
 
zhuyebb posted on 2019-8-20 12:59 I also tried leaving the other pins floating, and the level did jump, and the broadcast also jumped

Have you tried it? I seem to have found a pattern, that is, IO0 to IO8 and IO14 are configured to output low level before sleep, and they will not jump after broadcast wake-up.

IO9-IO11 have internal pull-ups and need to be configured to a high level before sleep, and will jump after waking up.

But I haven't found any exact instructions.

This post is from ST - Low Power RF
 
 
 

Just looking around
Find a datasheet?

EEWorld Datasheet Technical Support

Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved 京B2-20211791 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号
快速回复 返回顶部 Return list