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

[SofLit]

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.

[AScha.3]

Just make a new project, with your settings in Cube, but no "user" program.

(you can use your actual project, just new-> stm32 project from existing .ioc --> give new name like xxx_V2 .)

Then (wait...) generate code , compile, set debug settings as you need, and debug.

Still not running ?

[FredS]

Hallo SofLit,

Thank you for your interest.

I added the electronic scheme I found on github (see below) and a screenshot from the relevant part of the Clock-Config. The complete project (as zip-file) takes ~16MB, isn't that too much? But I guess the relevant info can be found in a limited set of files, like 'main.c', 'stm32h7xx_it.c', 'stm32h7xx_hal_msp.c' and '<project>.ioc'. Will uploading these files provide you the wanted info?

Greetings, Fred Schimmel

[FredS]

Hallo AScha.3,

Thank you for your effort to help me out.

I followed the "recipy" you prescribed, but unfortunately the result is effectively not different: Arriving on the statement

if (__HAL_FLASH_GET_LATENCY() != FLatency)

I did a debug "step-in", which brought the debugger in an undefined state: not 'running' but also the buttons for 'stepping' were greyed-out. Then I pushed on the button 'Suspend', and got in the well-known state where 'Disassembly' shows:

fffffffe: Failed to execute MI command:
-data-disassemble -s 4294967294 -e 4294967470 -- 2
Error message from debugger back end:
Cannot access memory at address 0xfffffffe

BTW: already before executing your proposed test, I uncoupled the WeAct board from the rest of my test-setup to eliminate possible influences from my HW. So, both the original project with my code included and the "stripped" project show the same error.

What should be a reasonable value for FLatency? I configured the clock at 0.5 x the max freq. (275 MHz, max = 550) so I expect a Latency of more than 0. I was reading RM0468 for more info on FLASH when your reply came in.

Greetings,

Fred Schimmel

[AScha.3]

Hi,

strange... :)

1. why set so "uneven" clocks ? see my setting for 200M +48 for usb:

2. why your pll multipier not shown ? see my pic.

3. check, what cube set for flash delay + core range settings:

+

did you enable debug ?

[SofLit]

If you can attach main.c and the ioc file.

[FredS]

Hallo AScha.3,

About the Clock settings: 1) the MCU is capable to run @ 550MHz, but the Clock Configuration panel showed 275MHz as maximum, so I changed my setting accordingly. It surprises me your picture shows other maxima than I see in my CUBEIDE. 2) The PLL-multiplier values are not shown because the value (x129) doesn't fit in its field (1 step magnification solves this).

About Voltage settings: 3) I did not change any value, so my project uses the defaults. Here also the window is a bit different, possibly another MCU. My window shows:

 About Debug: 4) You are right, I didn't configure the debug feature, I was not familiar with the new layout where Debug is a separate item. Despite that, I could run the debugger before switching it <on>. After switching the result was identical, error @ line 1139 of file 'stm32h7xx_hal_rcc.c'.

Hope this helps,

Fred Schimmel