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

PStorage handler only called when compiled under DEBUG (eclipse gcc)

I have a pstorage Clear and Store that I use just before calling bootloader_app_start() in my DFU bootloader code. Everything was working great testing/compiling (GCC) under debug. But when I compile a release, the pstorage_raw_clear() and pstorage_raw_store() calls never prompt the handler callback function. I've tested over and over to verify.

I used a while loop to wait until the callback handler clears a variable: while (pstorage_wait_flag) { sd_app_evt_wait(); }

But this seems to never return under a release compile. I've never had an issue like this before so I've very confused as to how to go about solving.

I am using SDK 6.1 S110 7.1. I am using raw mode and clearing One pg of Flash (1024b) and Storing One pg of Flash (1024b). I also have a One pg global static Ram buffer. Thank in advance for the assistance guys.

DC

Parents
  • Any assert()s in your code which are getting entirely compiled out under NDEBUG? Looking at the preprocessed output sometimes helps that.

    compiler know that pstorage_wait_flag is volatile and not optimising it away? These days I often build optimised code still with full debug symbols, doesn't make the actual code different or slower or larger, and the debugs do bounce around a bit, but it sometimes gives some clues down at the assembler level what's been optimized out.

  • I mean do you have any code which looks like this

    assert( some_important_function_call() == SUCCESS_VALUE );
    

    instead of

    uint32_t return_code = some_important_function_call();
    assert( return_code == SUCCESS_VALUE );
    

    That's a surprisingly easy way to break release builds.

    And why not also try setting the flag to volatile so the compiler knows not to optimise out the loop.

Reply
  • I mean do you have any code which looks like this

    assert( some_important_function_call() == SUCCESS_VALUE );
    

    instead of

    uint32_t return_code = some_important_function_call();
    assert( return_code == SUCCESS_VALUE );
    

    That's a surprisingly easy way to break release builds.

    And why not also try setting the flag to volatile so the compiler knows not to optimise out the loop.

Children
No Data
Related