[SOLVED] C-compiler generates unaligned strd instruction - hard fault

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] C-compiler generates unaligned strd instruction - hard fault

    Hi,

    I have a C-project which runs on NRF52832 (cortex M4). Using Segger Embedded Studio Release 5.10b (Build 2020091601.43513 Linux x64), segger-cc: version 10.6.6.

    My issue is the compiler generates an strd instruction using an unaligned address, which causes a hard fault when I run it.

    C-code:

    Source Code

    1. int mbedtls_sha256_starts_ret( mbedtls_sha256_context *ctx, int is224 )
    2. {
    3. SHA256_VALIDATE_RET( ctx != NULL );
    4. SHA256_VALIDATE_RET( is224 == 0 || is224 == 1 );
    5. ctx->total[0] = 0;
    6. ctx->total[1] = 0;
    7. if( is224 == 0 )
    8. {
    9. /* SHA-256 */
    10. ctx->state[0] = 0x6A09E667;
    11. ctx->state[1] = 0xBB67AE85;
    12. ctx->state[2] = 0x3C6EF372;
    13. ctx->state[3] = 0xA54FF53A;
    14. ctx->state[4] = 0x510E527F;
    15. ctx->state[5] = 0x9B05688C;
    16. ctx->state[6] = 0x1F83D9AB;
    17. ctx->state[7] = 0x5BE0CD19;
    18. }
    19. else
    20. {
    21. /* SHA-224 */
    22. ctx->state[0] = 0xC1059ED8;
    23. ctx->state[1] = 0x367CD507;
    24. ctx->state[2] = 0x3070DD17;
    25. ctx->state[3] = 0xF70E5939;
    26. ctx->state[4] = 0xFFC00B31;
    27. ctx->state[5] = 0x68581511;
    28. ctx->state[6] = 0x64F98FA7;
    29. ctx->state[7] = 0xBEFA4FA4;
    30. }
    31. ctx->is224 = is224;
    32. return( 0 );
    33. }
    Display All
    When compiling with optimization level 0, everything runs fine.


    However, when changing optimization level to 1 (and above), the following code is generated by the compiler (only parts of generated code shown):


    Source Code

    1. 6681 str r1, [r0, #0x68]
    2. F04F0C00 mov.w r12, #0
    3. F64473A4 movw r3, #0x4FA4
    4. F6CB63FA movt r3, #0xBEFA
    5. 2900 cmp r1, #0
    6. BF04 itt eq
    7. F64C5319 movweq r3, #0xCD19
    8. F6C533E0 movteq r3, #0x5BE0
    9. F64872A7 movw r2, #0x8FA7
    10. F2C642F9 movt r2, #0x64F9
    11. BF04 itt eq
    12. F64D12AB movweq r2, #0xD9AB
    13. F6C17283 movteq r2, #0x1F83
    14. E9C02308 strd r2, r3, [r0, #32]
    Display All


    The issue is the last line (#14), causing a hard fault because the address in r0 is 0x2000637a which is not 32-bit aligned. Changing the address to 0x2000637c before executing the line causes no hard fault.
    Edit: The address in question (0x2000637a) is the first parameter in the function (*ctx).

    The question is; is this caused by me and something I have configured wrong in my project? Or is this a bug in the compiler?

    Best regards.

    The post was edited 1 time, last by cnaess ().

  • Hello,

    Thank you for your inquiry.
    Such an issue is not known to us.
    Could you provide a project for reproduction which runs on an eval board?

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hello,

    We took a look at your example code. According to the addresses you see when debugging, 0x2000637a is not aligned correctly which means that your struct is called/used incorrectly. It should be 4 byte aligned but is 2 byte aligned instead.
    This is not a bug in the compiler but incorrect usage of the C language.
    It is pure luck that gcc creates other code here that runs by accident.

    We recommend to revisit your application and how that struct is used.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi, thank you for taking the time to look into this.

    SEGGER - Nino wrote:

    0x2000637a is not aligned correctly which means that your struct is called/used incorrectly. It should be 4 byte aligned but is 2 byte aligned instead.
    The address of the struct (0x2000637a) is assigned by the compiler. I'm not sure how I can instruct the compiler to use a 4 byte aligned address instead?
    Here's the code where it's assigned (the struct is ctx).:


    Source Code

    1. int mbedtls_sha256_ret( const unsigned char *input,
    2. size_t ilen,
    3. unsigned char output[32],
    4. int is224 )
    5. {
    6. int ret;
    7. mbedtls_sha256_context ctx;
    8. SHA256_VALIDATE_RET( is224 == 0 || is224 == 1 );
    9. SHA256_VALIDATE_RET( ilen == 0 || input != NULL );
    10. SHA256_VALIDATE_RET( (unsigned char *)output != NULL );
    11. mbedtls_sha256_init( &ctx );
    12. if( ( ret = mbedtls_sha256_starts_ret( &ctx, is224 ) ) != 0 )
    13. goto exit;
    14. if( ( ret = mbedtls_sha256_update_ret( &ctx, input, ilen ) ) != 0 )
    15. goto exit;
    16. if( ( ret = mbedtls_sha256_finish_ret( &ctx, output ) ) != 0 )
    17. goto exit;
    18. exit:
    19. mbedtls_sha256_free( &ctx );
    20. return( ret );
    21. }
    Display All
    mbedtls_sha256_init:




    Source Code

    1. void mbedtls_sha256_init( mbedtls_sha256_context *ctx )
    2. {
    3. SHA256_VALIDATE( ctx != NULL );
    4. memset( ctx, 0, sizeof( mbedtls_sha256_context ) );
    5. }


    Here's the definition of the struct:


    Source Code

    1. typedef struct mbedtls_sha256_context
    2. {
    3. uint32_t total[2]; /*!< The number of Bytes processed. */
    4. uint32_t state[8]; /*!< The intermediate digest state. */
    5. unsigned char buffer[64]; /*!< The data block being processed. */
    6. int is224; /*!< Determines which function to use:
    7. 0: Use SHA-256, or 1: Use SHA-224. */
    8. }
    9. mbedtls_sha256_context;

    SEGGER - Nino wrote:

    We recommend to revisit your application and how that struct is used.
    Could you please suggest how to change the code in order for the compiler to assign a 4 byte aligned address to ctx?

    Thank you.
  • Hello,

    Thank you for providing additional details.

    I can't see anything wrong with this code.
    The local variable 'ctx' is placed on the stack by the compiler, and because it contains a 'uint32_t', it will always be 4 bytes aligned (relative to the sp register).
    That means: Either the stack pointer was not setup correctly (sp must always be 4 byte aligned !) or the alignment was switched off by any unusual compiler directive (like -fpack-struct, -mstack-alignment, #pragma pack, .....)

    Are you using "stock" Embedded Studio or one with Nordic plugins/modifications. Could you attach your emProject file for reference to check if no project options are active that might cause this behaviour?
    If using a modified version of ES. Do you see the same behaviour with stock ES?

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hello and sorry about the late follow up.

    I finally had time to look into this. And after examining my project further I discovered the option "Unaligned Access Support" was set to "Yes". Changing this configuration to "No" resolved my issue.

    Thanks for your help!
  • Hello,

    Great to hear that you are up and running again.
    We will consider this thread as solved now.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.