HW or SW issue?

FredS · ‎2024-05-10

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

FredS · ‎2024-05-10

Hallo SofLit,

Sorry to let you wait, I was busy with the reply to AScha.3.

Please find the 'main.c' and 'STM32H723VGT6_CCDpos_Isolated_v2.0.ioc' as attached files.

I hope you may find the info you are looking for.

Thanks for your help,

Fred Schimmel

FredS · ‎2024-05-10

Hallo AScha.3 and SofLit,

Maybe a *** question, but I pose it anyway: I know that HardDisks have a feature to "disable" pieces of storage to manage errors without disposal of the whole device, if I remember well these rejected pieces are called "bad blocks". Is such a mechanism also applicable to a MCU internal Flash memory? In fact it primarily is the compiler / loader that should skip the bad address(es).

Just an idea by someone who is not hindered by too much dedicated knowledge .....

In advance: have a nice weekend,

Fred Schimmel

AScha.3 · ‎2024-05-10

Fred,

i just can show you my setup - its on H743 (480 M max.), so almost same.

BUT scale 2 -> 275 M core + 0 WS waitstates -> cannot work. Just wrong. Cube silly here or -- i dont know.

I have IDE 1.13.1 running , on Laptop 1.14.1 . I didnt try V 1.15.x , because many report problems after update.

IF this is an error in Cube, try setting my setup , also the WS .

see flash/wait for H723 :

If i read this, i'd say: you need 2 WS at 275MHz core . (same as on my H743 )

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

AScha.3 · ‎2024-05-10

> Is such a mechanism also applicable to a MCU internal Flash memory?

No, if you buy a original STM cpu with 1MB flash, it has tested 1MB working 100% .

This is not a sdcard, with internal bad block management and a "maybe work speed" .

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

Pavel A. · ‎2024-05-10

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.

FredS · ‎2024-05-10

Hallo AScha.3,

CUBEIDE doesn't let me modify the FLASH-WaitState, there is an asterix, poinnting to the statement "the setting is adjusted automatically when the Voltage-scale is set" (or something similar). I'm amazed about the relation, by trial and error I found the following relation:

- Volt scale 0 3WS (4 CPU cycles)

- Volt scale 1 0WS (1 CPU cycle)

- Volt scale 2 0WS (1 CPU cycle)

- Volt scale 3 0WS (1 CPU cycle)

I tried a debug session with Volt scale 1: the previous error showed up again. Then, with setting 'Volt scale 0' => 3WS my problem looks to be solved. I got another error, now something with SPI, but not the repeating line 1139 of file 'stm32h7xx_hal_rcc.c' !

About what you mention about the origin of the Board / MCU-chip: yes, you are right, this is the backside of buying cheap stuff.

I also realize I should investigate how to set the number WS by writing the Register, to see if there is a more sophisticated solution.

Thank you, SofLit and also Pavel.A for your willingness to help other people with their insight and knowledge. It is nice to know there are people around, willing to spend some time to help.

Have a nice weekend,

Fred Schimmel