HW or SW issue?

[FredS]

Hallo,

I needed more performance for my project, so I replaced my STM32F401 Blackpill by a WeAct STM32H723VGT6 board. I adapted my HW to accomodate the different layout of the H723 board and modified my application where needed because differences in various registers. When done I built my project with STM32CUBEIDE version 1.15.1 , upload it and tried to run it in Debug mode. I apply a simple 4wire ST-Link for the upload and debug communication.

Unfortunately, already in the second configuration statement I encounter an error, stating that a specific memory address cannot be read. I will try to give as much info as I can, hoping that more experienced members are able to conclude if this is a HW issue (just a bad part in the memory) or a SW error (just a case of bad code).

With trial and error I determined the exact statement that produces the error. The picture below shows the 'Debug' window and the window with the 'Disassembly' control.

 The content of the 'Disassembly output' is shown here:

0800542a: and.w r3, r3, #2
0800542e: cmp r3, #0
08005430: beq.n 0x8005454 <HAL_RCC_ClockConfig+560>
08005432: ldr r3, [r7, #4]
1132 if (FLatency < __HAL_FLASH_GET_LATENCY())
08005434: ldr r2, [r3, #12]
08005436: ldr r3, [pc, #80] @ (0x8005488 <HAL_RCC_ClockConfig+612>)
08005438: ldr r3, [r3, #24]
0800543a: and.w r3, r3, #15
0800543e: cmp r2, r3
08005440: movs r3, #1
1135 __HAL_FLASH_SET_LATENCY(FLatency);
08005442: b.n 0x8005552 <HAL_RCC_ClockConfig+814>
08005444: movs r0, #0
08005446: strh r0, [r0, r0]
08005448: add r0, r0
0800544a: ldr r2, [r0, r0]
0800544c: ldr r3, [r7, #4]
0800544e: ldr r3, [r3, #0]
08005450: and.w r3, r3, #4
1139 if (__HAL_FLASH_GET_LATENCY() != FLatency)
08005452: lsls r4, r0, #12
08005454: cmp r3, #0
08005456: Failed to execute MI command:
 -data-disassemble -s 134239318 -e 134239502 -- 3
 Error message from debugger back end:
 Cannot access memory at address 0x800545a
08005457: Failed to execute MI command:
 -data-disassemble -s 134239319 -e 134239503 -- 3
 Error message from debugger back end:
 Cannot access memory at address 0x800545a
08005458: Failed to execute MI command:
 -data-disassemble -s 134239320 -e 134239504 -- 3
 Error message from debugger back end:
 Cannot access memory at address 0x800545a
08005459: Failed to execute MI command:
 -data-disassemble -s 134239321 -e 134239505 -- 3
 Error message from debugger back end:
 Cannot access memory at address 0x800545a
0800545a: Failed to execute MI command:
 -data-disassemble -s 134239322 -e 134239506 -- 3
 Error message from debugger back end:
 Cannot access memory at address 0x800545a
0800545b: ldr r2, [r3, #16]
0800545d: ldr r3, [pc, #252] @ (0x800555c <HAL_RCC_ClockConfig+824>)
0800545f: ldr r3, [r3, #24]
1141 return HAL_ERROR;
08005460: bcs.n 0x800548c <HAL_RCC_ClockConfig+616>
08005462: ldr r3, [pc, #32] @ (0x8005484 <HAL_RCC_ClockConfig+608>)
08005464: ldr r3, [r3, #0]
08005466: bic.w r2, r3, #15
0800546a: ldr r1, [pc, #24] @ (0x8005484 <HAL_RCC_ClockConfig+608>)
1146 if (((RCC_ClkInitStruct->ClockType) & RCC_CLOCKTYPE_D1PCLK1) == RCC_CLOCKTYPE_D1PCLK1)
0800546c: ldr r3, [r7, #0]
0800546e: orrs r3, r2

 The problem is caused by the statement '__HAL_FLASH_SET_LATENCY(FLatency);' which matches the statement I stepped into in my debug stepping. It struck me the error occurs just at a point where the latency of Flash access is checked after adjustment. Is just just a coincidence or an understandable reason for this error?

This problem is repeatable, which gives me the impression I face a HW error in the Flash memory. However, I'm not experiencend in MCU programming, so maybe I'm wrong. Can anyone shed some light??

Thanks in advance,

Fred Schimmel

[AScha.3]

Hi,

how you made the project - with Cube/HAL ?

Then you should get a warning, when setting something "impossible" .

On H7 series you have to set core votage, flash waitstates, etc. according to core speed, you set in clock tree.

(Cube doing this for you.)

[FredS]

Hallo AScha.3,

Thank you for your very quick response.

Indeed, I use STM32CUBEIDE and HAL, certainly in the initial phase, because I'm not experienced in MCU programming. The error occurs in a CUBEIDE generated piece of code, but I'm aware this is no garantee for being without flaws. Also I don't understand how the code is intended to work, see the snippet below:

 /* Decreasing the number of wait states because of lower CPU frequency */
 if (FLatency < __HAL_FLASH_GET_LATENCY())
 {
 /* Program the new number of wait states to the LATENCY bits in the FLASH_ACR register */
 __HAL_FLASH_SET_LATENCY(FLatency);

 /* Check that the new number of wait states is taken into account to access the Flash
 memory by reading the FLASH_ACR register */
 if (__HAL_FLASH_GET_LATENCY() != FLatency)
 {
 return HAL_ERROR;
 }
 }

In line 2 is checked if the 'FLASH_LATENCY' is > FLatency (which appears to be 0 !), so the 'TRUE-clause' is executed. There the 'FLASH_LATENCY' is adjusted to FLatency (=> 0), followed by a check on the readback of the adjusted 'FLASH_LATENCY'. This statement appears to fail, possibly by adjusting the Latency to 0 (????)

I did a project-wide search for the declaration and assignment of the global 'FLatency' and could not find it. I don't understand how FLatency can be used without declaration. And a value of 0 may be the origin of the problem (???) I didn't dare to set it to another value to try, as I can't oversee the consequences.

What do you think?

Fred Schimmel

[mƎALLEm]

Hello,

You need at least provide the board schematics + Your system clock config.

Better to attach your project (including the ioc file) as other members could help you efficiently.

[Pavel A.]

Looks like mismatch of core clock and selected voltage scale. Do not set the core clock to max. Begin with ~ 40 ...60 Mhz. Why voltage scale 2? If you would like remote assistance to start your board, here it is available.

Note also that the newer generation of STM32H7 single cores (72/73, 7A/7B) have subtle differences from H743/75x, so use recipes for the older MCUs with caution.