I would like to know what the shading means in the left margin of the source code window in debug. It is mostly a very light gray but certain parts of it are a darker gray so it look like a bunch of little dark gray blocks. I can't for the life of me figure out if it relates to comments or blocks of code or what. Since I am troubleshooting some code that does not seem to be getting executed it would be helpful to know. I am using uVision MDK-Lite V4.72.10.0 for a STM32F0 processor.
Thanks.
Mike
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?
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.