GUI_INTERFACE utility functions tries to read from memory outside memory region

[DDeba.1]

Hi, 

I am using an STM32G0B1CBT and using the example shown in the following video to implement a USB-C PD sink with TRACER_EMB and UI_INTERFACE utilities for debugging. 

https://www.youtube.com/watch?v=-vsJhNIaHxE

After compiling and running the code, I noticed that the function BSP_GUI_LoadDataFromFlash at line 80 is trying to read from flash address 0x803F800, which is outside the memory region of 128k for the STM32G0B1CBT MCU. 

What can be the issue?

Thanks

 

[FBL]

Hi @DDeba.1 

It is possible GUI interface is intended for application with more flash footprint. So, BSP provided is not dependent on the target, users should implement appropriate boundary checks in their code to prevent accessing invalid memory regions. Also, it is possible to customize and optimize your code.

[DDeba.1]

Hi @FBL ,

I generated the code using the STM32CubeMX after selecting the proper device part number (STM32G0B1CBT). The GUI Interface and TRACER_EBM where both greyed out at first. After enabling USART1, the TRACER_EBM became available to use. Than after enabling the tracer on the USB PD, the GUI INTERFACE became available to use. In such case, I would expect that the code is generated according to the selected device .Moreover, the address from which the function is trying to read is define in a macro called GUI_FLASH_MAGIC_NUMBER. After following this macro, I see that this is defined through a number of other macros found in smt32g0xx_hal_flash.h which is also generated by the STM32CubeMX. 

Any idea of why the STM32CubeMX would generate wring values in these files? Is this a bug? Or at least, is there a way I can go around it to debug my application?

 

Thanks

[FBL]

Hi @DDeba.1 

First, check size of your code!  it is not expected to see writing outside the Flash, the linker should not allow it.

[DDeba.1]

Hi @FBL, 

Code size is 89.8kB (70.16% of 128K). I checked the linker and the flash size is correctly defined as 128K. I have attached the code in case someone wants to give a deeper check (its a simple USB-C PD app generated by the CubeMX). 

[DDeba.1]

Hi @FBL 

I might be finding some issues in the device itself now. I checked the datasheet again and it says that the STM32G0B1CB device which the datasheet lists as having 128k memory. This is also confirmed when I connect to the device using STM32CubeProgrammer. 

When I run the example code, I see that the GUI library is at the end getting the flash size from the stm32g0b1xx.h file using the FLASHSIZE_BASE macro. According to the datasheet, this is the memory address holding the memory size value of the device. So if I am understanding correctly, it is the device itself which is giving a wrong value. Am I seeing this right?

 

 

 

 

 

 

[DDeba.1]

Any ideas on a possible solution please?

[FBL]

Hi @DDeba.1 

Thank you for reporting this issue and details.

AFAIK, FLASH_SALES_TYPE_Pos is not addressing position. It indicates a sort of product identification sales number to be shifted as detailed in header flash defines:

 

#define OB_DUAL_BANK_BASE (FLASH_R_BASE + 0x20U) /*!< Not use cmsis FLASH alias to avoid iar warning about volatile reading sequence */
#define FLASH_SALES_TYPE_Pos (24U)
#define FLASH_SALES_TYPE (0x3UL << FLASH_SALES_TYPE_Pos) /*!< 0x000001E0 */
#define FLASH_SALES_TYPE_0 (0x1UL << FLASH_SALES_TYPE_Pos) /*!< 0x01000000 */
#define FLASH_SALES_TYPE_1 (0x2UL << FLASH_SALES_TYPE_Pos) /*!< 0x02000000 */
#define FLASH_SALES_VALUE ((*((uint32_t *)PACKAGE_BASE)) & (FLASH_SALES_TYPE))
#define OB_DUAL_BANK_VALUE ((*((uint32_t *)OB_DUAL_BANK_BASE)) & (FLASH_OPTR_DUAL_BANK))
#define FLASH_BANK_NB (((FLASH_SALES_VALUE == 0U)\
 || ((FLASH_SALES_VALUE == FLASH_SALES_TYPE_0) && (OB_DUAL_BANK_VALUE == 0U)))?1U:2U)

 

So, it seems to be an error in the definition of the FLASH_BANK_NB macro. To be checked internally with our dedicated team (203408). Also, INDEX_PAGE macro should not be using the 2 bank.