Hi Sir, I am using the STM32L011F3 on the Boot0 (PB9) pin as a key interrupt input pin. However, it doesn’t seem to respond to keypress to change state. Is there any special setting that need to perform to re-use Boot0 pin as GPIO pin?

[jason239955_st]

..

[waclawek.jan]

Read out and check/post the GPIOB registers content.

What's your hardware? How do you change the PB9 pin's voltage? Measure voltage directly on the pin.

JW

[jason239955_st]

Hi Sir,

Perform the below test code for PB7, PB9 and check IDR reading:

(External circuit to these 2 pins are disconnected)

while (1)

     {

           opr_state = GPIOB->IDR & GPIO_IDR_ID7;

           opr_state = GPIOB->IDR & GPIO_IDR_ID9;

           delay_ms(200);

     }

Result:

    1V   1.2V  1.4V   1.45V   1.5V  2V

PB7: 0      0     0      1       1   1

    0V  0.1V  0.2V 0.3V  0.4V  0.5V ---- 1V 1.3V 1.4V 1.5V 2V

PB9: 0   0     0    0     0     0         1  1    1    1   1

OK   OK    OK   OK    <--- hang at delay---->    OK   OK  OK

 

Observations:

1. For PB9, when power supply voltage is increased from 0V to 1V, there is a

momentary high current drawn of > 8mA. If power supply current limit

is set at 1mA, can see a momentary voltage drop then return to 1V.

1. For PB7, under similar setting, no such phenomenon.
2. There seems to have a region of indeterminate between 0.4V to 1.3V

for PB9.

1. The hanged condition is similar to the observation described in item#12 below.

However, the voltage at PB9 at the time of testing item #12 was 1.8V.

1. With the above information, re-confirming set#1 test below with B+ 4V. PB9 voltage

is 2.75V. Same condition as (1) – (3) below. Set hanged after start-up.

1. Suspect the 0.1uF capacitor connected to PB9 may cause the slow rise in PB9

voltage resulting in hanged state.

1. Remove the 0.1uF cap improved the rise time considerably, but set still hanged

after start-up.

• In summary, in my opinion, PB9/boot0 pin has some inherit problems.             OK. Perform the below test code for PB7, PB9 and check IDR reading:
• (External circuit to these 2 pins are disconnected)
• while (1)
•      {
•            opr_state = GPIOB->IDR & GPIO_IDR_ID7;
•            opr_state = GPIOB->IDR & GPIO_IDR_ID9;
•            delay_ms(200);
•      }
•  
• Result:
•     1V   1.2V  1.4V   1.45V   1.5V  2V
• PB7: 0      0     0      1       1   1
•  
•     0V  0.1V  0.2V 0.3V  0.4V  0.5V ---- 1V 1.3V 1.4V 1.5V 2V
• PB9: 0   0     0    0     0     0         1  1    1    1   1
• OK   OK    OK   OK    <--- hang at delay---->    OK   OK  OK
•  
• Observations:

1. For PB9, when power supply voltage is increased from 0V to 1V, there is a

• momentary high current drawn of > 8mA. If power supply current limit
• is set at 1mA, can see a momentary voltage drop then return to 1V.

1. For PB7, under similar setting, no such phenomenon.
   1. There seems to have a region of indeterminate between 0.4V to 1.3V

• for PB9.

1. The hanged condition is similar to the observation described in item#12 below.

• However, the voltage at PB9 at the time of testing item #12 was 1.8V.

1. With the above information, re-confirming set#1 test below with B+ 4V. PB9 voltage

• is 2.75V. Same condition as (1) – (3) below. Set hanged after start-up.

1. Suspect the 0.1uF capacitor connected to PB9 may cause the slow rise in PB9

• voltage resulting in hanged state.

1. Remove the 0.1uF cap improved the rise time considerably, but set still hanged

• after start-up.

[jason239955_st]

Hi Sir,

Below are the configuration as follows:

1. The switch (key/button) is connected to Li battery (3.2 – 4.2V). Call this voltage B+.
2. When the switch/key is pressed, it connects to a divider to bring the voltage down to 1.35 – 1.9V over the range of the battery voltage.

This divided down voltage is connected to Boot0/PB9. Before key-press, boot0/PB9 is at ground due to the divider.

I am currently testing the board with B+ 4V external, and 3.3V using the ST link programmer during debugging.

1. In addition, the switch also turns ON a 3V regulator to provide Vdd to the MCU.
2. So, upon first key-press, the MCU will boot from cold and start up in default state.
3. Subsequent key-press, the MCU will response to change state.
4. Upon a long key-press, the MCU will be switched OFF and power (Vdd) will be disconnected.
5. The next key-press will repeat from (d).

I did some testing yesterday and got the following observations:

          (Before the test, the program was confirmed to work with PB7 as the switch input pin. Only made changes to re-configure PB7 to PB9 with EXTI and GPIO change over)

1. Set #1. Program with stm32CubeProgrammer. After the program has been flashed in, re-load option byte with nBoot_sel checked (ie nBoot_sel=1), and nboot0 checked (ie nboot0=1).

[ref manual says nboot0=1 to boot from flash but cubepgmr says otherwise. However, tested out, nboot0 needs to be checked to boot from flash, I think]

1. Tested without debugger with Vdd=4V. Upon keypress, set start-ups at default state.
2. Subsequent keypress, no response. Set is in hanged state.
3. Set#2. Program with stm32CubeProgrammer. Reset the option byte setting to nboot_sel unchecked and nboot0 unchecked.
4. Test without debugger with Vdd = 4V. Upon keypress, mcu cannot boot up.
5. Many subsequent key presses, mcu cannot start up.
6. Re-wired the circuit to put both sets to stand-by before key-press.

ie before key-press, mcu is already powered up by 3V and should boot-up according to option byte for set#1 and boot0 pin for set#2.

1. Expect both sets to work normal. However, to my surprise, both sets cannot start up!
2. Test set#1 with stm32CubeIDE debugger. Since CubeIDE cannot modify option byte, so I think this is irrelevant as long as the program can run on the debugger.
3. Using step-into and step-over, I found that the program can run as long as the key is not pressed. Once the key is pressed, the debugger will switch over to ‘continue’ and in ‘run mode’ and the system hanged.
4. Input voltage level is not an issue, it can detect 1 when the key is pressed.
5. However, after the key is pressed and detected 1, subsequent step-into or step-over can only work for statement codes or macro. It will hang if step-into or step over a function. For example, before key-press, step-over delay function has no problem, but after the key is pressed, step-over delay function will hang. Any function for that matter. The debugger can step-into and step-over any of these functions if the key is not pressed. Once the key is pressed, it can step through statements but will hang in the next function call!
6. Test out the same program with another set re-configure for PB7. There is no such problem. The program can run smoothly after key-press.
7. Somehow, after the boot0 pin goes hi, the program seems to have been re-directed to elsewhere.

Any clue from the above observations?