In CubeMX my project has the option "Dual Core Boot Mode" = "Both CPUs booting at once". After generating code, I compile it in Keil. Linker complains:

"

Build target 'new from scratch Eval_CM7'
linking...
new from scratch Eval_CM7\new from scratch Eval_CM7.sct(7): error: L6235E: More than one section matches selector - cannot all be FIRST/LAST.
Not enough information to list image symbols.
Not enough information to list load addresses in the image map.
Finished: 2 information, 0 warning and 1 error messages.
"new from scratch Eval_CM7\new from scratch Eval_CM7.axf" - 1 Error(s), 0 Warning(s).

"

Should I fix something in CubeMX or in Keil options?

Create a *very* simple project. For example, have each core toggle a pin that you would put an LED on (the embedded "hello world").

I suspect (have zero direct cubeMX experience, that keil has command-line options that will fix the problem.

A simple google "cubemx" found this forum: https://community.arm.com/developer/tools-software/tools/f/keil-forum/35995/should-i-use-cubemx

and https://www.keil.com/pack/doc/STM32Cube/General/html/cubemx.html

Thank you for support. I tried few very simple projects in CubeMX on DualCore STM32H747 - the same problem happens in Keil: conflict in .sct file. This file is generated by Keil, not CubeMX.

I have positive experience with CubeMX + Keil on the SingleCore STM32F745, it works well with all ADCs DACs UART etc. It's .sct file is:

; *************************************************************

; *** Scatter-Loading Description File generated by uVision ***

; *************************************************************

LR_IROM1 0x08000000 0x00100000  {    ; load region size_region

  ER_IROM1 0x08000000 0x00100000  {  ; load address = execution address

   *.o (RESET, +First)

   *(InRoot$$Sections)

   .ANY (+RO)

  }

  RW_IRAM1 0x20000000 0x00040000  {  ; RW data

   .ANY (+RW +ZI)

  }

}

For the DualCore STM32H747 M7 core the .sct file looks the same, especially the problem 7th line in bold:

; *************************************************************

; *** Scatter-Loading Description File generated by uVision ***

; *************************************************************

LR_IROM1 0x08000000 0x00100000  {    ; load region size_region

  ER_IROM1 0x08000000 0x00100000  {  ; load address = execution address

   *.o (RESET, +First)

   *(InRoot$$Sections)

   .ANY (+RO)

  }

  RW_IRAM1 0x20000000 0x20020000{  ; RW data

   .ANY (+RW +ZI)

  }

}

There are two .sct files, for each core. This is the M4 .sct file:

; *************************************************************

; *** Scatter-Loading Description File generated by uVision ***

; *************************************************************

LR_IROM1 0x08100000 0x00100000  {    ; load region size_region

  ER_IROM1 0x08100000 0x00100000  {  ; load address = execution address

   *.o (RESET, +First)

   *(InRoot$$Sections)

   .ANY (+RO)

  }

  RW_IRAM1 0x10000000 0x10048000{  ; RW data

   .ANY (+RW +ZI)

  }

}

Linker tab in Target Options has these lines:

--cpu Cortex-M4.fp *.o 

--library_type=microlib --strict --scatter "new from scratch Eval_CM4\new from scratch Eval_CM4.sct" 

--summary_stderr --info summarysizes --map --xref --callgraph --symbols 

--info sizes --info totals --info unused --info veneers 

 --list "new from scratch Eval_CM4.map" 

-o "new from scratch Eval_CM4\new from scratch Eval_CM4.axf" 

Addresses in .sct files are different, but the problem 7th line is always the same. I guess, Linker is confused which core goes first? No problem for the SingleCore MCU... How to edit this? And what's the purpose of .sct file?

Thanks!

Not having the tools..

I would look at the command-line options for all of the tools, esp the ones that generates the .sct files.

Have you tried editing a .sct file and changing +First to +Second  ?

You can also call customer service at Keil....

https://developer.arm.com/docs/100070/0612/scatter-loading-features

a lot of reading, and no any simple working example for the DualCore MCU...

L6235E: More than one section matches selector - cannot all be FIRST/LAST.

See the following in the armlink User Guide:

• Section placement with the FIRST and LAST attributes.
• Syntax of an input section description.

quote: If you are not using scatter-loading, use the --first and --last linker command-line options to place input sections.

So - are you using the --first options? Have you tried using --last on the second file compile?

Not clear to me when you have three compiled units &7 want to link them.

new from scratch Eval_CM7\new from scratch Eval_CM7.axf: Error: L6200E: Symbol ADC3_IRQHandler multiply defined (by startup_stm32h747xx_cm7.o and startup_stm32h747xx_cm4.o).

new from scratch Eval_CM7\new from scratch Eval_CM7.axf: Error: L6200E: Symbol ADC_IRQHandler multiply defined (by startup_stm32h747xx_cm7.o and startup_stm32h747xx_cm4.o).

I guess: the same parameter is declared twice, in CM4 and CM7. May be problem is here. Apparently for the working example, both .sct files use option First, only memory layout is different (that's what I don't understand):

CM4.sct:

LR_IROM1 0x08100000 0x00100000  {    ; load region size_region

  ER_IROM1 0x08100000 0x00100000  {  ; load address = execution address

   *.o (RESET, +First)

   *(InRoot$$Sections)

   .ANY (+RO)

  }

  RW_IRAM1 0x10000000 0x00040000  {  ; RW data

   .ANY (+RW +ZI)

  }

}

CM7.sct:

LR_IROM1 0x08000000 0x00100000  {    ; load region size_region

  ER_IROM1 0x08000000 0x00100000  {  ; load address = execution address

   *.o (RESET, +First)

   *(InRoot$$Sections)

   .ANY (+RO)

  }

  RW_IRAM1 0x24000000 0x00080000  {  ; RW data

   .ANY (+RW +ZI)

  }

}

i would call keil - it's their toolchain.

This also has the flavor of something "minor" is missing - the solution is missing but "minor", in the sense when you find the solution, it will be a single small detail.

and solution was: in Keil Application/MDK-ARM folder (which had two files), delete this M4 file

startup_stm32h747xx_CM4.s

and keep this M7 file

startup_stm32h747xx_CM7.s

They are exactly the same. Who put two of them, not sure, maybe CubeMX? All other non-CubeMX examples have only single file

startup_stm32h747xx.s

Yep - one of those problems creating forehead-shaped holes that have a simple solution. The Deamon Murphy has a 3-day attention span.

Thasnks for letting us know what the solution was.

yours ... bandit

My experience is not with this particular processor, so this is speculation.

I have been using the STM32WB55 dual core processor both on the eval boards and a project. 

When I used CubeMX to generate base code, it would not run properly. However, the non-CubeMX example code would run properly.

I compared the load files (*.ld) and found that the load addresses were different in the examples and the generated files.

I suggest that you try one of the examples to see that they work and then use the LD file from the example. Be careful, though. When CubeMX generates code, it also writes over the ld file, so you will need to copy the correct ld file over the generated one.

Just a guess that you have the same scenario. Worth a check.

Thanks for the support. Yes, I tried example codes: Dual-Core Blinky and FPU Fractals - the only two examples available today for STM32H747. They both are non-CubeMX. I compiled them, loaded, they work great. They have .ld files! But my CubeMX-initiated project, after compilation in Keil, doesn't have .ld files...

BTW those working non-CubeMX initiated examples, also have .sct files, with the same 7th line, which Keil complains about in my project:

   *.o (RESET, +First)

although these blocks are different:

  RW_IRAM1 0x38000000 0x00010000  {  ; RW data

   .ANY (+RW +ZI)

  }

  RW_IRAM2 0x24000000 0x00080000  {

   .ANY (+RW +ZI)

  }

Is .ld file mandatory? And what's the purpose of this code above in .sct files?

Thanks!

Sorry, I don't use Keil, so I can't speak to that.

I use the STM32CubeIDE and that was the source of the erroneous load file.

But, having a working example is a great place to start when comparing non-working support files with working ones. Has to be there. Getting Hello World or Blinky wrong is hard to do.