2024-05-16 04:37 PM
I have been looking at the power consumption on an STM32U031K8U6 when it is put into standby mode with the RTC setup to regularly wake up the processor. Most recently I had the wake-up time set to 250ms. The processor wakes up and does the following
- the requisite initialization
- resets the RTC wakeup timer
- gets a wakeup count from a backup register and increments it
- if the wakeup count is greater than or equal to 40:
* the wakeup count is set back to zero
* an LED is turned
* HAL_Delay(5) is called
* the LED is turned off.
- the new wake up count is written into the backup register
- HAL_PWR_EnterSTANDBYMode() is called to put the MCU back into standby mode.
------------
The above code works as expected.
I have been using STM32CubeIDE with the Device Configuring Tool to do this work.
I have been running the MCU off of the MSI clock.
I had done multiple builds with the MSI set for lower clock rate, The latest was 200K before I built a load with the MSI set for 48M. I loaded that 48M build onto my test board using the run facility of the IDE.
The code ran as expected and my average current consumption was significantly lower.,
For the next build, I checked the "Set all free pin as analog (to optimize consumption)" box in the Project Manager tab of the Device Configuration Tool. I created the build and attempted to load it onto my board. The attempt timed out.
My setup uses a J-Link debugger. I had to setup the run configuration to connect to a remote GDB server because the one that STM23CubeIDE calls by default is an older one that does not support the STM32U0 series.
I manually started Seggers J-Link GDB Server 7.96h and set it up for the STM32U031K8 and the GDB port referenced in the run configuration. After the above failure the GDB server will not connect to the processor. The following is the explanation from the GDB log file:
-------------------------------------
02-00000000-00-00000528-0026: TD2D8 230:585.120 InitTarget() start
02-00000000-00-00000528-003F: TD2D8 230:585.136 J-Link Script File: Executing InitTarget()
02-00000000-00-00000675-0056: TD2D8 230:732.752 RDP Level 1 protection is set. Reading flash memory is restricted.
02-00000000-00-00000678-0030: TD2D8 230:734.544 RDP Level 1 password is set.
02-00000000-00-00000678-00AC: TD2D8 230:734.560 To unlock device please use Device Provisioner utility for STM32U0 option-bytes programming: https://wiki.segger.com/ST_STM32U0_Option_Bytes_Programming
-------------------------------------
As you can see, the processor is in RDP 1 mode which is preventing the connection. I did nothing that I am aware of to put the processor into this mode. The only change in that load from the previous was the clock speed. I made no changes to the run configurion.
This debug/GDB setup worked to load the processor multiple time until a similar failure two days ago. I switched to a different development board and tried again assuming that the lockup was just a fluke. Once again, I was able to load the processor multiple time before I had this problem.
Does anyone have any Idea what could be causing RDP 1 mode to be set?
Thanks.
Solved! Go to Solution.
2024-05-17 03:01 PM
It turned that this problem was not because RDP level 1 protection was set as the GDB log said. This happened because the program puts the processor into standby mode, and I had just increased the clock speed to 48M. The device was going back into standby mode before the debugger could connect.
The fix was to use STM32CubeProgrammer with an STLINKV2 and setting the reset mode to Hardware Reset".
The switch to using a STLINKV2 was required because STM32CubeProgrammer calls an older version of J-LINK that does not support the STM32U0 series yet.
Several folks from ST helped with getting this figured out.
Thanks.
2024-05-17 03:01 PM
It turned that this problem was not because RDP level 1 protection was set as the GDB log said. This happened because the program puts the processor into standby mode, and I had just increased the clock speed to 48M. The device was going back into standby mode before the debugger could connect.
The fix was to use STM32CubeProgrammer with an STLINKV2 and setting the reset mode to Hardware Reset".
The switch to using a STLINKV2 was required because STM32CubeProgrammer calls an older version of J-LINK that does not support the STM32U0 series yet.
Several folks from ST helped with getting this figured out.
Thanks.
2024-05-17 03:05 PM
One other thing. We tried STM32CubeProgreammer first and were able to erase the chip.
The debugger in the IDE works as well after setting it up to use the STLINKV2 and "Connect under reset".
2024-05-24 09:10 AM
I am programming my stm32f4 and rpd got accidentally set to FF and cannot revert it back to AA. what could be the issue and how to solve this problem?