cancel
Showing results for 
Search instead for 
Did you mean: 

what are the difference between rev3 and rev4 for the stm32f43xx ?

Aball.1
Associate II

Hello

I have encountered a strange problem at work using stm32f439zi processors.

Some context:

We're using two board:

  • development board NUCLEO-F439ZI, with a processor stm32f439ZITx in revision 4
  • custom board, with a processor stm32f439ZIYx in revision 3

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.

1 ACCEPTED SOLUTION

Accepted Solutions

> 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

View solution in original post

4 REPLIES 4

> 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

Aball.1
Associate II

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

Aball.1
Associate II

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

Thanks for coming back with the solution.

JW