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.

[onio]

alister just saw this reply. I am currently trying to debug STM32H7B3I_DISCO_2_Images_Loader. SBSFU has the ability to optionally use the Standalone loader or use its inbuilt one.

When running the standalone one I can load the image into the STM32H7B3i-DK board using STM32CubeProgrammer and see the loader program start running by seeing the debug print statements.

[alister]

I was answering your earlier comment "I am not using the debugger because of the jumping around of the code" and the later comment "Regarding the disabling compiler optimization I don't believe it is possible".

It is possible.

[alister]

> I can load the image into the STM32H7B3i-DK board using STM32CubeProgrammer

I'd not understood your comment. Have you a question about debugging the SBSFU's installing the downloaded app from slot #1?

My method wasn't elegant. I didn't think of using STM32CubeProgrammer.

I'd used TrueSTUDIO. CubeIDE will be similar. I modified the startup script of the SBSFU's debug configuration to load the app's header to the swap sector (to trigger the SBSFU's install) and the app's image to slot #1.

Then the debugger would throw a reset before starting the debug session and I had to stop that triggering the SBSFU before I'd debugged it. So for debugging only, I modified SBSFU's main to loop on a temporary variable until I'd changed its value in the debugger.

[onio]

Alister when I said "disabling compiler optimization I don't believe it is possible" I was not merely referring to jumping around as code does when trying to single step through code that has optimization -O3 and can easily be solved by changing to -O0.

Below is a main() of the standalone external loader that jumps to another program.

/**
  * @brief  Main program
  * @param  None
  * @retval None
  */
int main(void)
{
  LOADER_StatusTypeDef e_ret_status;
  uint32_t uRxSize;
 
  
  /* Enable the CPU Cache */
  CPU_CACHE_Enable();
 
  /* STM32H7xx HAL library initialization:
  - Configure the Flash prefetch
  - Systick timer is configured by default as source of time base, but user
  can eventually implement his proper time base source (a general purpose
  timer for example or other time source), keeping in mind that Time base
  duration should be kept 1ms since PPP_TIMEOUT_VALUEs are defined and
  handled in milliseconds basis.
  - Set NVIC Group Priority to 4
  - Low Level Initialization
  */
  HAL_Init();
 
  /* Configure the system clock */
  SystemClock_Config();
 
  /* LED Init*/
  BSP_LED_Init(LOADER_STATUS_LED);
 
  /* Initialize external flash interface (OSPI/QSPI) */
  LOADER_LL_FLASH_Init();
 
  /* If the SecureBoot configured the IWDG, loader must reload IWDG counter with value defined in the reload register */
  WRITE_REG(IWDG1->KR, IWDG_KEY_RELOAD);
 
  /* Configure Communication module */
  LOADER_LL_UART_Init();
  
  TRACE("\r\n======================================================================");
  TRACE("\r\n=                      YModem Loader                                 =");
  TRACE("\r\n======================================================================");
  TRACE("\r\n");
 
  /* Loader initialization */
  e_ret_status = LOADER_Init();
  if (e_ret_status != LOADER_OK)
  {
    TRACE("Initialization failure : reset !");
    NVIC_SystemReset();
  }
 
  /* Download new firmware */
  e_ret_status = LOADER_DownloadNewUserFw(&uRxSize);
  if (e_ret_status == LOADER_OK)
  {
    TRACE("\r\nDownload successful : %d bytes received\r\n", uRxSize);
    LOADER_InstallAtNextReset((uint8_t *) SLOT_DWL_REGION_START);
  }
  else
  {
    /* Standalone loader communication : request executed - no other request */
    (*(uint32_t *)LOADER_COM_REGION_RAM_START) = STANDALONE_LOADER_NO_REQ;
 
    TRACE("\r\nDownload failed (%d)\r\n", e_ret_status);
    LOADER_LL_FLASH_Erase_Size((void *) SLOT_DWL_REGION_START, SLOT_DWL_REGION_SIZE);
  }
 
  /* Reset to restart SBSFU */
  NVIC_SystemReset();
}

After the statement NVIC_SystemReset() program control jumps to another part of memory and starts executing the code and in the case the SBSFU.

If this is what you meant about been possible with the debugger, then I would like to know how as I currently don't know how to handle this as of yet.

Thanks once again.

[onio]

alister the answer to the question is yes and no but for me to explain I think a bit of background history is required. 

We have an existing master controller which is IOT enabled. One of the task of this controller is to be used for uploading new 

secure firmware image to our custom board which is running STM32H7B0 via I2C instead or YMODEM protocol.

The custom board has an external 4Mbytes onboard flash that we would like to use for storing the firmware. 

For us to continue development while we waited for custom hardware I started developing on the STM32H7B3i-DK

which allowed me to make the changes from using YMODEM to using I2C.

The SBSFU has a loader built in its project or can use the standalone loader. The option that I am going with is using the

SBSFU with the external loader. I use STM32CubeProgrammer for uploading loader image into the target (STM32H7B3i-DK) and 

then the loader image now running on the target prompts for the user application to be uploaded via I2C.

This whole process of downloading the user application works on the STM32H7B3i-DK board, however not under debug. So I can'target

set breakpoints etc.

Now that I have recently received our custom board my next task is to try and port the code running on the STM32H7B3i-DK to our

custom board running STM32H7B0.

And with this I was hoping that I can get debug working as it would make developing much faster.

[alister]

This has nothing at all to do with compiler optimization.

As you are debugging the application or boot code, it is not formal testing, so you may change the code to make the microcontroller execute the code paths you want to debug.

The comment on the write to LOADER_COM_REGION_RAM_START is too cryptic for me to understand.

You've downloaded an application image. You'd like to debug the SBSFU's validating and installing it...

Before downloading, you need to load a modified SBSFU that will neither install it nor change it except by your control.

The NVIC_SystemReset is irrelevant to us. We may test NVIC_SystemReset works correctly without debugging anyway.

After downloading the application image and executing NVIC_SystemReset, you switch your project to the SBSFU and begin debugging that from its entry point or main.

This is the case I'd described in my previous comment.

While the debugger has control of the microcontroller, you need to manually enable its operation (e.g. set the value of some variable in your .bss to non-zero) so the SBSFU will proceed to validate and install the image. This is just the first step. You need to break it down and contrive a method to reach each path you want to debug.

[alister]

>And with this I was hoping that I can get debug working as it would make developing much faster.

Your circumstances are the same as any developer. The X-CUBE-SBSFU is an example. Most everyone would chuck out the YMODEM. It's there to encourage the developer to take ownership and replace it with something appropriate to their product.

I mentioned one problem that prevents reducing optimization in an earlier post, i.e. __get_LR needs to be inlined, but gcc disables inlining at low optimization , so you have to force it. Expect to have to fix bugs/problems . Step until it won't. Figure out why. Fix (or contrive). Repeat.

[onio]

alister, I have already replaced the YMODEM protocol with the I2C and that works fine on the STM32H7B3i-DK board. Using the I2C, I was able to load the example UserApp.sfb image to the board. What I am doing now is porting X-CUBE-SBSFU code to our custom board.

[alister]

>What I am doing now is porting X-CUBE-SBSFU code to our custom board.

You've done more than me. I went straight to a custom board. It wasn't fast development. Took many months. Some parts aren't finished...

[onio]

We have actually changed boards with processor 3 times (STM32L073, STM32H750 and STM32H7B0) due to one thing or another. We started by implementing our own secure bootloader but then abandoned it when we realized that ST had an offering.

And with each processor various development board which also involved porting. This my first project involving STM32 development so still finding my way around things.

The X-CUBE-SBSFU hopefully is the final hurdle of the project. Once I am able to get secure code running on our custom board with RTOS then I am home free.

alister which ST micro-controller are you using?