Crossworks 2.x vs. 3.x : Differences and crashes

Comments

3 comments

  • Avatar
    Michael Johnson

    1) V3 uses different compilers so you'll get different code sizes

    2) Sounds like stack size problems

    3) The .hzs files seem to cause problems - delete them when switching between major versions

    There's no way to use the v2 compilers/libraries with v3. We did this in v2 to keep support for v1 but it was a nightmare. Unfortunately there's no way to change things and keep them the same. With v3 we have supplied both GCC and Clang/LLVM compilers. I would recommend that you show your source code to both compilers. The notation that an application only works with a specific version of a compiler is usually a problem with the application not the compiler.

    0
    Comment actions Permalink
  • Avatar
    Matt

    1) Understood.  Goes to my question about whether there is a migration guide or more detail about what changed.  The larger project compiled to about 100k less than the 2.x.  This implies serious optimization or something significantly different that we would like to understand.  The compiler options for optimization in the project file has not changed, so while we do expect some code size changes, we want to make sure that it is soley due to compiler changes vs. compiler changes + possible other settings becoming active in the project itself.

    2) It does, doesn't it?  No settings were changed at the Crossworks level for stack size.  But if 3.x handles this differently than 2.x, we'd like to know.  If you think it is just the compiler difference filtering down into a stack issue, o.k.  But that doesn't quite jive with the fact that the offending issue was an unused variable in a structure that changed from a value of 0x05 to 0x00, resulted in a 3 byte difference in the overall hex file, and hard faulted. 

    3) Did I miss this in a migration guide?  That is pretty important information, and can probably help.  I will try to see if this helps with the other problems as well.

     

    I can understand the nightmare and empathize.  We don't want to support 2.x anymore either...the 3.x interface is better.  And yes, I'm sure we have issues in our application, I just also believe that there are some issues in the 3.x setup that we don't fully understand or have insight into, hence the migration guide question.

    Thank you for the response!

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    1) Enable Unused Symbol Removal is turned on by default - so this will remove any symbols that can't be referenced from the entry point.

    2) It could be using more or less stack, there could be alignment issues (but I think Cortex-M3/M4 don't fault on misaligned access).

    3) There are some words in the release notes regarding tbss sections. The .hzs file thing is a bug that I've failed to reproduce.

    0
    Comment actions Permalink

Please sign in to leave a comment.