2

I have a code that works really fine with an -O1 optimization, but that crashes if I don't optimize the code. The last lines that are executing are the following :

    OSCCTRL_CRITICAL_SECTION_ENTER();
    ((Oscctrl *)hw)->DFLLCTRL.reg = data;

If I put a breakpoint on this last line, and then go to the next instruction, then the debugger will lose track of the execution pointer.

This code is called as part of the chip initialization which is the following succession of functions :

void _init_chip(void)
{
    hri_nvmctrl_set_CTRLB_RWS_bf(NVMCTRL, CONF_NVM_WAIT_STATE);
    _set_performance_level(2);
    OSC32KCTRL->RTCCTRL.bit.RTCSEL = 0x4;
    _osc32kctrl_init_sources();
    _oscctrl_init_sources();
    _mclk_init();
    _gclk_init_generators();
    _oscctrl_init_referenced_generators();
}

The buggy line is called by the _oscctrl_init_referenced_generators(); line.

I would like to know the differences between optimized and non-optimized code, and if you guys any known issues with non-optimized embedded code. I am developping on a SAML21J18B MCU, embedding a Cortex-M0+ CPU.

YohjiNakamoto
  • 373
  • 2
  • 12
  • 5
    It's highly likely that your code exhibits **undefined behaviour** (e.g. invalid pointer), which simply has different side effects depending on the compilation level. – Oliver Charlesworth Sep 02 '16 at 10:47
  • If I optimized and break this exact piece of code, then it crashes too. However if I don't break at this position of the code, it will work fine. – YohjiNakamoto Sep 02 '16 at 10:52
  • 2
    If it "loses track" then that usually means that your critical section could not be entered and the code is blocking. Synchronization bugs are very often timing-sensitive so the whether or not code is optimized certainly matters. Don't expect to get anything done for the next week :) – Hans Passant Sep 02 '16 at 11:05
  • What do you mean ? Is it a bug that is really hard to debug ? – YohjiNakamoto Sep 02 '16 at 11:20
  • there is a difference between optimized and unoptimized. and using a debugger to single step or breakpoint is a whole other thing itself as it is not a natural flow/execution of the program. – old_timer Sep 02 '16 at 13:10
  • we would need more information, optimized vs not optimized is usually a problem with your code, sometimes but rarely the compiler. using a debugger no matter what the optimization level is a whole other thing so we would need to see more and know what chip this is, etc. cortex-m0 is not relevant so much as it is the chip that matters and this perpheral. – old_timer Sep 02 '16 at 13:12
  • The PLL hardware registers are vendor specific not generic to Cortex-M0; more information is necessary. Since PLL set-up often requires special care, you should include all the PLL set-up code not just the lines on which it appears to be failing. The definition of `OSCCTRL_CRITICAL_SECTION_ENTER` may also be required. The question has already attracted a close vote due to lack of necessary information for debugging. – Clifford Sep 02 '16 at 14:02
  • I added complementary precisions to the initial question. – YohjiNakamoto Sep 02 '16 at 14:43

3 Answers3

3

I'm going a different direction than the other answer and the comments. Looking at your code, it looks like you're playing with the oscillator control, and so I'm thinking that you are not using the correct process for configuring or adjusting the oscillator.

Depending on what you are trying to do, you may need to switch to a different clock before adjusting oscillator parameters, and by breaking and stepping, you may be losing your clock. When you don't optimize, there are probably some extra instructions that are causing the same result.

Consult the part's reference manual and make sure you're doing everything correctly. For this line of thinking, though, your question needs more of the code in that area and the model of microcontroller (not just the core type).

rjp
  • 1,760
  • 13
  • 15
0

The most obvious effect of optimizations will be the debuggers ability to display execution state. The act of debugging can interfere with program execution. Specifically for this chip certain oscillator configurations can cause problems.

The debugger is probably not your problem however. If you step into _oscctrl_init_referenced_generators(); you will likely find that one of your configured oscillators is not starting and that the code is waiting for the DFLL or FDPLL to obtain a stable frequency lock. There can be a variety of reasons for this. Check that the upstream oscillators are configured and running.

Logan Greenlee
  • 41
  • 3
-1

In short, the difference is that the optimization depending on its type may simplify some code constructions, as well as change the location of the data in the memory. Thus, in most cases such a behavior signals about the code design is not made well. Most typical reasons are the use of non-initialized variables, hanging pointers, out of boundary access or the having similar issues. Thus, you should avoid code constructions which depend on assumptions which might become wrong due to optimization. Depending on the compiler and optimization level, the use of volatile might also help in some cases.

Also, if you perform at least a tight code review + static code analysis, and ensure there are no compiller warnings the behavior should remain the same independently from optimization.

dmi
  • 1,424
  • 1
  • 9
  • 9