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

Comments

15 comments

  • Avatar
    Gordon Scott

    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
  • Avatar
    Michael Johnson

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

    0
    Comment actions Permalink
  • Avatar
    Gordon Scott

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

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

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

    0
    Comment actions Permalink
  • Avatar
    Gordon Scott

    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
  • Avatar
    Michael Johnson

    That's the problem you should use

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

    0
    Comment actions Permalink
  • Avatar
    Gordon Scott

    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
  • Avatar
    Michael Johnson

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

    0
    Comment actions Permalink
  • Avatar
    Gordon Scott

    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
  • Avatar
    Michael Johnson

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

    0
    Comment actions Permalink
  • Avatar
    Gordon Scott

    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
  • Avatar
    Michael Johnson

    The target processor property should be available then.

    0
    Comment actions Permalink
  • Avatar
    Gordon Scott

    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
  • Avatar
    Taleb Bendiab Zakaria

    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
  • Avatar
    Michael Johnson

    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.