Problem debugging the STM32H7B3i-DK (Again)

[onio]

I am developing on the STM32H7B3i-DK board using Keil MDK + STMCubeMx for creating the project.

For some bizarre reason that I can't explain, I can no longer do debugging on my dev board after been blocked for a few days by an issues that I had with "option bytes".

Now the option bytes issue was resolved I tried to continue with my debugging only to discover that I can not longer do debugging on the board which was kind of working.

Every time I run the debugger it seems to crash in the following function. The value passed in the SupplySource parameter is PWD_LDO_SUPPLY.

HAL_StatusTypeDef HAL_PWREx_ConfigSupply (uint32_t SupplySource)
{
  ,,,
  /* Set the power supply configuration */
  MODIFY_REG (PWR->CR3, PWR_SUPPLY_CONFIG_MASK, SupplySource);
  ,,,
}

Once the code tries to execute the line MODIFY_REG(PWR->CR3, PWR_SUPPLY_CONFIG_MASK, SupplySource) it crashes with the following dialog box message

At which point I can no longer continue with the debug session other than to power cycle the board or else I start to get other error messages such as

Followed by

Are other experiencing issues with this board. So far I have used the STM32H750, STM32H743 and the STM32L073 without any issues.

For some reason I seems to have spent 80% of my time fighting one issue or another on this board rather than my development.

Is there a decent tutorial on this board that one can follow or there known issues about this device that I should know off.

Thanks in advance.

[alister]

I've seen you other post https://community.st.com/s/question/0D53W00000GXsdnSAD/problem-running-sbsfu-with-keil-rtx5-rtos.

If your SBSFU (bootloader) executing on reset? Consider its purpose and that your using JTAG/SWD (to debug your application) is what it's designed to prevent.

What RDP, PCROP, MPU regions, etc is it enabling? Hopefully not RDP level 2!

BTW what is your core?

Before starting a debug session, clear its PCROP, RDP, etc.

Consider implementing two versions of your SBSFU: one for laboratory debug and development and one for the field, and don't enable RDP, PCROP, DAP, etc in the debug one. Also assigning your debug one different secret keys, in case someone accidentally moves a debug board from your secure and guarded development laboratory into the field.

[M.Hajji · Accepted solution]

Hello Onio,

From UM2569 page 17, the board is designed for SMPS only as default config which mean you need the SMPS enabled.

By using LDO_SUPPLY you are enabling LDO and disabling the SMPS thus you have no 1.2V supplied to the core and your debugger connection crash.

Try "PWR_DIRECT_SMPS_SUPPLY" or change it in your CubeMX project withing RCC parameters (see attached).

Hope my suggestion help.

Hajji.

[M.Hajji]

In the CubeMX Repository there is examples/projects (running on STM32H7B3i-DK) and code template you can start with.

For the known limitations of the device, check the Errata.

Regards,

Hajji.

[onio]

Hi M.Hajji,

Thanks your suggestion definitely helped. Yes it was the power supply setting issue. The only bit I need to figure out was why it seemed to have worked last week.

At least for now it is sorted so I can press on again. Thanks

[onio]

Hi alister,

The issue reported in this thread has now been solved Thanks.

=========================

Thanks for your reply. When I am running the SBSFU code I am not using the debugger because of the jumping around of the code. So I simply program the SBSFU firmware with STM32CubeProgrammer and the bootloader then allows me to load my code which for now is the UserApp project.

Without the RTOS as part of the UserApp build things seems to work fine. I can change the UserApp code and see the changes when I program using the SBSFU loader. The problem I see comes into play when I introduce RTOS which requires that I remove some default handler in order to use the one that is part of of the RTOS library.

I am not entire such if this issue is to do with the RTOS or C++(Micro-Lib not supported). Later on today I would try and isolate the problem by decoupling RTOS, C++ and micro-Lib from the UserApp and see which one breaks it.

In regarding the enabling of the security feature. The default SBSFU build enables all the security features when programmed using STM32CubeProgrammer. I have identified the Flag in the code which should be used to turn on and off the security features from been used. When I start to properly debug the code I would do this for my development environment.

Thanks.

[onio]

Thanks Hajji, once again.

[alister]

>I am not using the debugger because of the jumping around of the code

Disable compiler optimization for your Debug configuration.

>when I introduce RTOS which requires that I remove some default handler 

You might change the SVC number SBSFU uses to enter privileged state. You must study and weigh: MPU for protection against inner attacks, or no MPU protection and use FreeRTOS, or to use FreeRTOS-MPU.

[onio]

Hey Alister,

Sorry for late reply, I was on Holiday last Friday and only started to look at this again today, Thanks for the response. I would get back on it and see if I can make the change to the SVC number.

Regarding the disabling compiler optimization I don't believe it is possible in my case. The SBSFU consist of 4 different project.

1. Stand alone loader
2. Encryption engine
3. SBSFU (Has an integrated loader or optionally use stand alone loader)
4. UserApp

The loader is responsible for loading the firmware image. The supplied example uses YModem protocol but I have changed our project to use I2C instead. The loader runs at startup and gives a prompt for the user to send firmware using the YModem for example. When the loader has finished receiving all the bytes for the host (sender) it then jumps to the UserApp through some internal hardware register. This action involves moving from the loader to the UserApp via a reset but preserving some register to make the jump.

[alister]

> I don't believe it is possible in my case

Which part are you debugging?

In se_intrinsics.h you'll need to fix __get_LR function wouldn't inline and so couldn't return LR with -O0 optimization. This fixes that.

__STATIC_FORCEINLINE uint32_t __get_LR(void)
{
  register uint32_t result;
  asm volatile("MOV %0, LR\n" : "=r"(result));
  return result;
}