Meaning of shading in source code margin debug window

Dark gray blocks indicate that debug line numbers for the
statements are available - that is, they relate to executable
code. You can set breakpoints at the dark gray marked statements,
you cannot on the light gray areas (no executable code).
Also, the context menu items 'Run to cursor line',
'Set PC at current line' are enabled only in 'dark gray' ranges.

Thanks for the response although that makes for more confusion. With the code below the two lines in a row that try to set HSEON are not dark gray. This makes me think that they are not being executed and no, I can't set a breakpoint on ether one of them. This code was generated by STM32f0xx_Clock_Configuration_V1.0.1.xls although I added the double setting of HSEON. This code does not seem to be starting up the HSE. I am also working with my ST FAE to make sure the crystal is hooked up right (I'm using a STM32F0 Discovery board). But, even if the crystal is not hooked up right I'd think the code below would turn on the HSEON bit. Are those two lines of code being optimized away for some reason?

Mike

static void SetSysClock(void)
{
  __IO uint32_t StartUpCounter = 0, HSEStatus = 0;

/******************************************************************************/
/*                        HSE used as System clock source                     */
/******************************************************************************/

  /* SYSCLK, HCLK, PCLK configuration ----------------------------------------*/
  /* Enable HSE */
  RCC->CR |= ((uint32_t)RCC_CR_HSEON);
  RCC->CR |= ((uint32_t)RCC_CR_HSEON);

  /* Wait till HSE is ready and if Time out is reached exit */
  do
  {
    HSEStatus = RCC->CR & RCC_CR_HSERDY;
    StartUpCounter++;
  } while((HSEStatus == 0) && (StartUpCounter != HSE_STARTUP_TIMEOUT));

  if ((RCC->CR & RCC_CR_HSERDY) != RESET)
  {
    HSEStatus = (uint32_t)0x01;
  }
  else
  {
    HSEStatus = (uint32_t)0x00;
  }

  if (HSEStatus == (uint32_t)0x01)
  {
    /* Enable Prefetch Buffer and set Flash Latency */
    FLASH->ACR = FLASH_ACR_PRFTBE | FLASH_ACR_LATENCY;

     /* HCLK = SYSCLK / 1 */
     RCC->CFGR |= (uint32_t)RCC_CFGR_HPRE_DIV1;

     /* PCLK = HCLK / 1 */
     RCC->CFGR |= (uint32_t)RCC_CFGR_PPRE_DIV1;

    /* Select HSE as system clock source */
    RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_SW));
    RCC->CFGR |= (uint32_t)RCC_CFGR_SW_HSE;

    /* Wait till HSE is used as system clock source */
    while ((RCC->CFGR & (uint32_t)RCC_CFGR_SWS) != (uint32_t)RCC_CFGR_SWS_HSE)
    {
    }
  }
  else
  { /* If HSE fails to start-up, the application will have wrong clock
         configuration. User can add here some code to deal with this error */
  }
}

I would first check for those missing statements by using Optimize-0.
In this case, the two HSEON lines must have dark gray markers.
At higher optimize levels, code may get merged/moved depending on
context. With -O0, when clicking at the first HSEON line in source
code, the disassembly view gets syncronized so that you will see the
corresponding code.

Thank you for your responses.

Yes, I do have the optimize flag set to 0.

Yes, makes sense to skim the manual some more, I do tend to just start hacking and whacking whenever I start with any new IDE. I did do some searching to find some mention of the shading without luck but it was a pretty cursory search. Anyway, I'm back on it this morning.

Mike