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?

[FBL]

Hi @DDeba.1 

Would you screenshot the content of register when getting the flash size from this address FLASHSIZE_BASE 0x1FFF75E0 ? Or using CubeProgrammer, try to read this address to check. You can use also LL_GetFlashSize() in your firmware.

[DDeba.1]

Hi, 

I checked. LL_GetFlashSize() returns the correct size (128) and FLASHSIZE_BASE 0x1FFF75E0 also has the correct value (0xFFFF0080). I did some more digging on the nested #defines and discovered the following. The issue is coming from the macro ADDR_FLASH_LAST_PAGE  which is defined as (FLASH_BASE + (INDEX_PAGE * FLASH_PAGE_SIZE)). The FLASH_BASE value is correct at 0x08000000. The FLASH_PAGE_SIZE is also correct at 0x00000800 (2KBytes). But the INDEX_PAGE value is set to 0x0000007F (127U). When computing the value of ADDR_FLASH_LAST_PAGE, this results in 0x0803F800 which is outside the memory region.

Looking deeper in the INDEX_PAGE macro, this is defined as ((FLASH_PAGE_NB * 2u) - 1u). Is this definition correct? Shouldn't the multiplication by 2U be made only if the device has a dual bank?

EDIT: looking again at the macro, it is defined as follows in the usbpd_gui_memmap.h file:

#if defined (FLASH_OPTR_DBANK) || defined(FLASH_DBANK_SUPPORT)

#define INDEX_PAGE ((FLASH_PAGE_NB * 2u) - 1u) /* Index of latest page */

#else

#define INDEX_PAGE (FLASH_PAGE_NB - 1u) /* Index of latest page */

#endif /* FLASH_OPTR_DBANK || FLASH_DBANK_SUPPORT */

So the header file correctly takes care if the device is dual bank or not. Digging again I found that the FLASH_BANK_NB macro returns 1 bank, while the definition of the INDEX_PAGE macro is using the 2 bank option since the FLASH_DBANK_SUPPORT is define in the stm32g0b1xx.h file. The macro FLASH_BANK_NB is defined as 

(((FLASH_SALES_VALUE == 0U)\
|| ((FLASH_SALES_VALUE == FLASH_SALES_TYPE_0) && (OB_DUAL_BANK_VALUE == 0U)))?1U:2U).

The FLASH_SALES_VALUE is 0U so the FLASH_BANK_NB is defined as 1U. Looking at this macro, its defined as  ((*((uint32_t *)PACKAGE_BASE)) & (FLASH_SALES_TYPE)). The PACKAGE_BASE value I read from memory (location 0x1FFF7500) is 0x00010304, giving a PKG[3:0] value of 4U (LQFP48 / UFQFPN48 GP version) for this device, which is correct. Looking at the FLASH_SALES_TYPE macro, it is defined as (0x3UL << FLASH_SALES_TYPE_Pos) where FLASH_SALES_TYPE_Pos is 24U. But at bit location [25:24] are not defined for the PACKAGE_BASE register as according to the reference manual (pg 1369), this register is 16bit. Is there an error in the definition of the FLASH_BANK_NB macro since PACKAGE_BASE location contains no info about flash base?