This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Thingy 52 mesh example at Segger Embedded studio issue

I am have a curious issue with thingy52-mesh-provisioning-demo repo at Nordic Semi github.

Prebuild hex behavior does not match with hex compiled by source.

In short, Double to uint32_t casting is wrong.

IMHO, something wrong with default compiler (or prebuild standard libraries - *.a) at Segger Embedded Studio.

I have replaced double round(double) calls to float roundf(float) for avoid double to uint32_t casting. It is ugly fix! =)

For details look at my issue at GitHub

Could you please help me or explain my misstep?

Parents
  • Hi Batov, 

    It's quite strange that you get the double 0 cast to uint32 2 . On my setup it's return 0 0 with your code. 
    Which compiler are you using ? Do you use the included gcc compiler comes with Segger ? 

  • Default compiler.

    Try to set optimization level to None (Not Debug)

    Case with wrong casting repeated for me at any Nordic project at SES.

  • I don't really have a clue what could be wrong here. 

    But in your log  there is a "App OnOff Model Handle: 2" would that value 2 came from that variable. There must be something causing the cast to result 2. Have you tried to do step debug when doing casting ? 
    And have you tried to make a minimum code just with the test function and nothing else ? 

  • Minimum code with same result. Set Optimization Level to None.

    IMHO, __eabi_d2uiz has bug.

    lsrs.w r0, r0, r2 put to r0 0x02

    Code sample which return 0x02 with any optimization level.

  • Hi Batov, 

    I have reproduced the issue here. It seems that there is an issue with the standard library from Segger (located in the lib folder) 
    This happened in v4.30c that you used and v4.40 latest as well. 

    I would suggest to try testing with v4.18 (or v4.22) . This is what I have in v4.18:

    We will try to contact Segger to check with them. 

Reply
  • Hi Batov, 

    I have reproduced the issue here. It seems that there is an issue with the standard library from Segger (located in the lib folder) 
    This happened in v4.30c that you used and v4.40 latest as well. 

    I would suggest to try testing with v4.18 (or v4.22) . This is what I have in v4.18:

    We will try to contact Segger to check with them. 

Children