2022-03-01 11:15 PM
Hello
I have encountered a strange problem at work using stm32f439zi processors.
Some context:
We're using two board:
The difference between the two processor are only the package and the revision.
We have a program developed in the stm32Cube that works well and is debuggable on both board.
We have an other program developed using mbedOS that works well on the development board but fails to launch on the custom board.
We starting a debug session, the mbed program crash and gives a segmentation fault.
Debug console of the crash:
```
Selected port 50000 for debugging
0001458:INFO:board:Target type is stm32f439xi
0001477:INFO:coresight_target:Asserting reset prior to connect
0001488:INFO:dap:DP IDR = 0x2ba01477 (v1 rev2)
0001515:INFO:ap:AHB-AP#0 IDR = 0x24770011 (AHB-AP var1 rev2)
0001601:INFO:rom_table:AHB-AP#0 Class 0x1 ROM table #0 @ 0xe00ff000 (designer=020 part=411)
0001743:INFO:rom_table:[0]
0001785:INFO:rom_table:[1]
0001788:INFO:rom_table:[2]
0001790:INFO:rom_table:[3]
0001792:INFO:rom_table:[4]
0001794:INFO:rom_table:[5]
0001795:INFO:cortex_m:CPU core #0 is Cortex-M4 r0p1
0001800:INFO:cortex_m:FPU present: FPv4-SP-D16-M
0001802:INFO:dwt:4 hardware watchpoints
0001806:INFO:fpb:6 hardware breakpoints, 4 literal comparators
0001820:INFO:coresight_target:Deasserting reset post connect
0001839:INFO:server:Semihost server started on port 4444 (core 0)
0001895:INFO:gdbserver:GDB server started on port 50000 (core 0)
Reading symbols from PATH/code.elf...
warning:
Loadable section "RW_IRAM1" outside of ELF segments
(no debugging symbols found)...done.
0003508:INFO:gdbserver:Client connected to port 50000!
warning: Loadable section "RW_IRAM1" outside of ELF segments
0x080002a4 in _printf_lc ()
0003724:INFO:gdbserver:Attempting to load argon
0003724:INFO:gdbserver:Attempting to load freertos
0003724:INFO:gdbserver:Attempting to load rtx5
0003725:INFO:gdbserver:rtx5 loaded successfully
Resetting target with halt
Successfully halted device on reset
Attached to debugger on port 50000
0022093:INFO:loader:Erased chip, programmed 32768 bytes (8 pages), skipped 0 bytes (0 pages) at 1.75 kB/s
Resetting target with halt
Successfully halted device on reset
Image loaded: PATH/code.elf
Note: automatically using hardware breakpoints for read-only addresses.
Program
received signal SIGSEGV, Segmentation fault.
0xd3000040 in ?? ()
```
After doing all the digging I could I'm certain only the package and the revision are different between the two processors.
Looking at the errata sheet for the processor (https://www.st.com/resource/en/errata_sheet/es0206-stm32f427437-and-stm32f429439-line-limitations-stmicroelectronics.pdf) it appears that there is no difference between the two revisions.
I dont get why there would be a revision without any change and I failed to find any information on what the differences could be.
Solved! Go to Solution.
2022-03-01 11:56 PM
> The difference between the two processor are only the package and the revision.
But the difference is also in the board itself, including effect of different external components connected and their handling in software, layout effects (e.g. signal crosstalk), power supply effects, effects of bad solder joints and shorts.
Also, there's no "segmentation fault" in Cortex-M4, but that appears to be limitation of the toolchain you are using. Gather more information.
Debug it in the usual way: observe registers content, observe RAM content, observe stack content, try to estimate execution path from stack; insert ; dissect/remove parts of code; etc.
> I dont get why there would be a revision without any change
There are many possible changes in manufacturing which result in no change in function described in RM and parameters given in DS. Also, some revisions simply mean transfer to a different fab. Particularly, rev.4 appears to be specifically WLCSP-targeted, so it would most probably be a change in the last level of metallization. The fact that ST a couple of years ago made significant effort to move all STM32Fxx production to TSMC, that rev.4 is Crolles-specific, together with timing appears to indicate that ST restarted production of the 'F42x in Crolles, probably on request of an important customer.
I don't say there is no error in rev.4, but in my experience, hardware errors are extremely rare and software errors are orders of magnitude more probable. Especially if you use code which you don't have full control of.
JW
2022-03-01 11:56 PM
> The difference between the two processor are only the package and the revision.
But the difference is also in the board itself, including effect of different external components connected and their handling in software, layout effects (e.g. signal crosstalk), power supply effects, effects of bad solder joints and shorts.
Also, there's no "segmentation fault" in Cortex-M4, but that appears to be limitation of the toolchain you are using. Gather more information.
Debug it in the usual way: observe registers content, observe RAM content, observe stack content, try to estimate execution path from stack; insert ; dissect/remove parts of code; etc.
> I dont get why there would be a revision without any change
There are many possible changes in manufacturing which result in no change in function described in RM and parameters given in DS. Also, some revisions simply mean transfer to a different fab. Particularly, rev.4 appears to be specifically WLCSP-targeted, so it would most probably be a change in the last level of metallization. The fact that ST a couple of years ago made significant effort to move all STM32Fxx production to TSMC, that rev.4 is Crolles-specific, together with timing appears to indicate that ST restarted production of the 'F42x in Crolles, probably on request of an important customer.
I don't say there is no error in rev.4, but in my experience, hardware errors are extremely rare and software errors are orders of magnitude more probable. Especially if you use code which you don't have full control of.
JW
2022-03-02 12:00 AM
We modified the development board to have it as close as possible to the custom board but the problem might very well come from the slight differences between the two boards.
Thank you for the answer about the revisions
2022-03-02 06:23 AM
Quick update for anyone having the same problem in the future.
The custom board left the BOOT0 pin open. This causes problems when loading the code as described in the following post : https://community.st.com/s/question/0D50X00009XkYDuSAN/hi-what-is-boot0-in-stm32
Have a nice day.
ABR
2022-03-02 08:33 AM
Thanks for coming back with the solution.
JW