2024-05-10 03:47 AM
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
Solved! Go to Solution.
2024-05-10 08:27 AM
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
2024-05-10 08:53 AM
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
2024-05-10 08:57 AM
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 )
2024-05-10 09:01 AM - edited 2024-05-10 09:02 AM
> 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" .
2024-05-10 09:19 AM - edited 2024-05-10 09:24 AM
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.
2024-05-10 12:00 PM
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