cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H563 hard fault when trying to read UID

continuum
Associate II

When I'm trying to read Unique device ID register on Nucleo-H563ZI, either by using HAL_GetUIDw0() or by doing

 

uint32_t uid1 = *((uint32_t*)0x08FFF800);

 

hard fault occurs. 

 

1 ACCEPTED SOLUTION

Accepted Solutions
STOne-32
ST Employee

Dear @continuum ,

You can refer to this similar case and also same solution. https://community.st.com/t5/stm32-mcu-products/using-dac-of-nucleo-h503rb/m-p/572203/highlight/true#M217994

Therefore, as mentioned by TDK you need to disable cacheability of this region of Read-Only (RO) for unique ID.
“By default, all the AHB memory range is cacheable. For regions where caching is not practical (OTP, RO), MPU has to be used to disable local cacheability.  

STM32H563/H573 and STM32H562 Arm<Sup>®</Sup>-based 32-bit MCUs - Reference manual Page 236

Hope it helps,

STOne-32

View solution in original post

8 REPLIES 8
TDK
Guru

Perhaps an MPU access violation.

If you feel a post has answered your question, please click "Accept as Solution".

I don't have MPU enabled. I noticed the hard fault happens only when accessing the UID register after enabling instruction cache (ICACHE).

Pavel A.
Evangelist III

If you don't enable ICACHE, no fault?

yes

STOne-32
ST Employee

Dear @continuum ,

You can refer to this similar case and also same solution. https://community.st.com/t5/stm32-mcu-products/using-dac-of-nucleo-h503rb/m-p/572203/highlight/true#M217994

Therefore, as mentioned by TDK you need to disable cacheability of this region of Read-Only (RO) for unique ID.
“By default, all the AHB memory range is cacheable. For regions where caching is not practical (OTP, RO), MPU has to be used to disable local cacheability.  

STM32H563/H573 and STM32H562 Arm<Sup>®</Sup>-based 32-bit MCUs - Reference manual Page 236

Hope it helps,

STOne-32

Pavel A.
Evangelist III

@STOne-32 Shouldn't things like this be in the errata?

Is this fault caused by loading NX data to ICACHE? kind of "speculative execution" bug on CM7 MCUs?

 

I have no experience working with MPU but I managed to make it work. 

These are the CubeMX settings that worked for me:

continuum_0-1692890741594.png

If I set something wrong, I would appreciate it if someone could point it out. 

// Disable instruction cache prior to internal cacheable memory update
if(HAL_OK != HAL_ICACHE_Disable())
Error_Handler();
// read UID

uint32_t u0 = HAL_GetUIDw0(); // X, Y coordinates
uint32_t u1 = HAL_GetUIDw1(); // Lot number (ASCII encoded)
// Re-enable instruction cache
if(HAL_OK != HAL_ICACHE_Enable())
Error_Handler();