"thumb_crt0.s:257: undefined reference to `__stack_end__'" placement sections

Follow

Gordon Scott

• November 20, 2014 09:20

I'm presently having link/loads fail with lots (*) of undefines like the following:

/usr/share/crossworks_for_arm_2.3/source/thumb_crt0.s:257: undefined reference to `__stack_end__'

(*) 13 different start/end pairs.

I've so far failed to find from where they are generated.

Can anyone shed some light?

Thanks.

              Gordon.

0

• 

  Gordon Scott

  • November 21, 2014 11:28

  I've just found the relevant file, though I have no idea at present why a find+grep failed to do so.

  These may be OpenBLT-specific memory sections.  TBC.

  0

  Comment actions Permalink
• 

  Michael Johnson

  • November 21, 2014 11:34

  These are generated from the section_placement.xml file - which section_placement.xml file are you using?

  0

  Comment actions Permalink
• 

  Gordon Scott

  • November 21, 2014 11:34

  No, they're referenced from thumb_crt0.s, which is automatically linked-in by Crossworks.

  0

  Comment actions Permalink
• 

  Michael Johnson

  • November 21, 2014 11:36

  The symbols __stack_end__ etc are generated from the section_placement.xml file by the link process.

  0

  Comment actions Permalink
• 

  Gordon Scott

  • November 21, 2014 11:55

  Hi Michael,

  My last post was almost concurrent with yours and referred to my post.

   

  $(StudioDir)/targets/flash_placement.xml

  $(TargetsDir)/STM32/STM32F207ZG_MemoryMap.xml

   

  The 'relevant' file that contained the sections was memory.x in the OpenBLT code tree, so may not be relevant.

  At the moment, I'm building a new copy of the solution to see if the problem just goes away. Other suggestions most welcome.

  0

  Comment actions Permalink
• 

  Michael Johnson

  • November 21, 2014 12:08

  That's the problem you should use

  $(StudioDir)/targets/CortexM/flash_placement.xml

  0

  Comment actions Permalink
• 

  Gordon Scott

  • November 21, 2014 12:23

  That sounded very encouraging, but it's made no difference :-(

  I did try deleting everything in the THUMB* directories, but to no avail.

  I don't know if this is relevant, but I can't see a "Target Processor" in the project properties.

  0

  Comment actions Permalink
• 

  Michael Johnson

  • November 21, 2014 12:30

  This is probably an old stm32f10x project - edit the .hzp file and change occurences of stm32f10x to stm32

  0

  Comment actions Permalink
• 

  Gordon Scott

  • November 21, 2014 12:48

  Hi Michael,

  I think it was originally for an STM32F103, though if so I've already changed all the stm32ff10x occurrences, though to stm32f2xx.  I can't find any where that looks wrong. I did just try changing the ..._Loader_prc.elf, but I doubt that's the problem. Restored to ..../STM32F2xx_Loader_rpc.elf

  0

  Comment actions Permalink
• 

  Michael Johnson

  • November 21, 2014 12:58

  There should be a property_groups.xml file this should be in the $(TargetsDir)/STM32 directory.

  0

  Comment actions Permalink
• 

  Gordon Scott

  • November 21, 2014 13:18

  There's a file propertyGroups.xml which is probably it. It has stuff about a range of processors, including the STM32F207ZG, and data there that looks sensible.  The settings in my properties seem to match OK.

  0

  Comment actions Permalink
• 

  Michael Johnson

  • November 21, 2014 13:23

  The target processor property should be available then.

  0

  Comment actions Permalink
• 

  Gordon Scott

  • November 21, 2014 14:45

  Hopefully this is now resolved.

  It occurred to me to copy the "Configuration Name Common" line from my work-in-progress .hzp to the non-working .hzp

  I couldn't see any obviously relevant differences, but, after adding an include path for the .vec file, it's built OK.

  I can only guess that there was something in that line that upset Crossworks in some way. I had edited the file for the F207, so I rather suspect it was something I did during that process.

  It's a shame that that line isn't structured one item per line, as a comparison between .hzp files would then be much easier. I have made that split to compare files, but the line has to be reconstituted to work. Not that either task is hard.

  Thanks for your help.

  Gordon.

  0

  Comment actions Permalink
• 

  Taleb Bendiab Zakaria

  • September 22, 2015 00:23

  hello

  i have the same problem with file thumb_crt0.s, like descibed in the attached picture.

  can anyone help me

  thanks

  0

  Comment actions Permalink
• 

  Michael Johnson

  • September 24, 2015 09:41

  You're using the CrossWorks v1 STM32F1xx CPU support package with CrossWorks v2. Use the STM32 CPU support package with CrossWorks v2 and CrossWorks v3.

  0

  Comment actions Permalink

Please sign in to leave a comment.