Forums

STM32F152 question

Started by sburck July 2, 2012
I'm setting up a new project on an STM32F152, and and having a problem with
the wakeup timer of the RTC.  It seems to be running, setting the interrupt
flag, and the interrupt is enabled, but not jumping to the handler.  I'm
using IAR's toolkit.  The code looks like this:


  SCB->VTOR = 0x08000000; 
  RCC->CR |= (uint32_t)0x00000100;

  /*!< Reset SW[1:0], HPRE[3:0], PPRE1[2:0], PPRE2[2:0], MCOSEL[2:0] and
MCOPRE[2:0] bits */
  RCC->CFGR &= (uint32_t)0x88FFC00C;

  /*!< Reset HSION, HSEON, CSSON and PLLON bits */
  RCC->CR &= (uint32_t)0xEEFEFFFE;

  /*!< Reset HSEBYP bit */
  RCC->CR &= (uint32_t)0xFFFBFFFF;

  /*!< Reset PLLSRC, PLLMUL[3:0] and PLLDIV[1:0] bits */
  RCC->CFGR &= (uint32_t)0xFF02FFFF;

  /*!< Disable all interrupts */
  RCC->CIR = 0x00000000;

  /*!< Configure the System clock frequency, HCLK, PCLK2 and PCLK1
prescalers */
  /*!< Configure the Flash Latency cycles and enable prefetch buffer */
//  SetSysClock();

  RCC->APB1ENR |= (1 << 28); // PWREN - Enable the power interface clock
  PWR->CR |= (1 << 8); // DBP - Disable backup write protection
  RCC->CSR |= (1 << 8); // LSEON - External low-speed oscillator enable
  while ((RCC->CSR & (1 << 9)) == 0) // wait for LSERDY: External low-speed
oscillator ready
    ; // insert timeot later ??????????
  RCC->CSR |= (1 << 16); // RTCSEL[1:0] - RTC and LCD clock source
selection: 0 - Off; 1 - LSE; 2 - LSI; 3 - HSE

  RTC->WRP = 0xCA;
  RTC->WRP = 0x53;  
  RTC->CR &= ~RTC_CR_WUTE; // enable wake up timer
  while ((RTC->ISR & RTC_ISR_WUTWF) == 0)
    ;
  RTC->WUTR = 10000; // play with this when we know what we need;
  RTC->CR &= ~(RTC_CR_WUCKSEL_2);
  RTC->CR |= RTC_CR_WUCKSEL_0 | RTC_CR_WUCKSEL_1; // RTC/16
  RTC->ISR &= ~RTC_ISR_WUTF;
  RTC->CR |= RTC_CR_WUTE; // enable wake up timer
  RCC->CSR |= RCC_CSR_RTCEN; // enable RTC as well.
  RTC->WRP = 0xFF ;

And when I look at the registers while running, I see that

RTC_CR = 0x00004403
which means, among other things WUTE and WUTIE are high.
I can also watch RTC_ISR->WUTF transition from low to high.

I have a handler defined at RTC_WKUP_IRQHandler, but it's not happening.

Anything I'm forgetting?

Thanks.	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com
On Mon, 02 Jul 2012 09:39:17 -0500, sburck wrote:

> I'm setting up a new project on an STM32F152, and and having a problem > with the wakeup timer of the RTC. It seems to be running, setting the > interrupt flag, and the interrupt is enabled, but not jumping to the > handler. I'm using IAR's toolkit. The code looks like this: > > > SCB->VTOR = 0x08000000; > RCC->CR |= (uint32_t)0x00000100; > > /*!< Reset SW[1:0], HPRE[3:0], PPRE1[2:0], PPRE2[2:0], MCOSEL[2:0] and > MCOPRE[2:0] bits */ > RCC->CFGR &= (uint32_t)0x88FFC00C; > > /*!< Reset HSION, HSEON, CSSON and PLLON bits */ > RCC->CR &= (uint32_t)0xEEFEFFFE; > > /*!< Reset HSEBYP bit */ > RCC->CR &= (uint32_t)0xFFFBFFFF; > > /*!< Reset PLLSRC, PLLMUL[3:0] and PLLDIV[1:0] bits */ > RCC->CFGR &= (uint32_t)0xFF02FFFF; > > /*!< Disable all interrupts */ > RCC->CIR = 0x00000000; > > /*!< Configure the System clock frequency, HCLK, PCLK2 and PCLK1 > prescalers */ > /*!< Configure the Flash Latency cycles and enable prefetch buffer */ > // SetSysClock(); > > RCC->APB1ENR |= (1 << 28); // PWREN - Enable the power interface clock > PWR->CR |= (1 << 8); // DBP - Disable backup write protection RCC->CSR > |= (1 << 8); // LSEON - External low-speed oscillator enable while > ((RCC->CSR & (1 << 9)) == 0) // wait for LSERDY: External low-speed > oscillator ready > ; // insert timeot later ?????????? > RCC->CSR |= (1 << 16); // RTCSEL[1:0] - RTC and LCD clock source > selection: 0 - Off; 1 - LSE; 2 - LSI; 3 - HSE > > RTC->WRP = 0xCA; > RTC->WRP = 0x53; > RTC->CR &= ~RTC_CR_WUTE; // enable wake up timer while ((RTC->ISR & > RTC_ISR_WUTWF) == 0) > ; > RTC->WUTR = 10000; // play with this when we know what we need; > RTC->CR &= ~(RTC_CR_WUCKSEL_2); > RTC->CR |= RTC_CR_WUCKSEL_0 | RTC_CR_WUCKSEL_1; // RTC/16 RTC->ISR &= > ~RTC_ISR_WUTF; > RTC->CR |= RTC_CR_WUTE; // enable wake up timer RCC->CSR |= > RCC_CSR_RTCEN; // enable RTC as well. > RTC->WRP = 0xFF ; > > And when I look at the registers while running, I see that > > RTC_CR = 0x00004403 which means, among other things WUTE and WUTIE are > high. > I can also watch RTC_ISR->WUTF transition from low to high. > > I have a handler defined at RTC_WKUP_IRQHandler, but it's not happening. >
I'm not familiar with that particular processor, but it looks like you've just set up the real time clock -- is there some global interrupt enable that has to be set, or some bit in the central interrupt hardware (whatever it's called on that processor)? Certainly if it were an ARM Cortex part you'd be missing an enable bit in the NVIC. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
Found it a while back and thought I'd come here and close this.  All the
devices on this need to be given a clock, and I didn't give it one.	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com
On Sun, 22 Jul 2012 06:30:16 -0500, "sburck" <2374@embeddedrelated>
wrote:

>Found it a while back and thought I'd come here and close this. All the >devices on this need to be given a clock, and I didn't give it one.
The lovely (ha!) thing about embedded processors is that quite often missing just a single bit in an obscure register is enough to "break" them. I wouldn't be surprised to learn that many (most?) STM32 "bare metal" developers were caught by this. For the most part, the datasheets, user's guides, and/or reference manuals are pretty darned good both in coverage and correctness. But it sure would be nice if manufacturers included a "quick start" section that mentioned all of the "oh by the ways." -- Rich Webb Norfolk, VA
Rich Webb wrote:

> On Sun, 22 Jul 2012 06:30:16 -0500, "sburck" <2374@embeddedrelated> > wrote: > >>Found it a while back and thought I'd come here and close this. All the >>devices on this need to be given a clock, and I didn't give it one. > > The lovely (ha!) thing about embedded processors is that quite often > missing just a single bit in an obscure register is enough to "break" > them. I wouldn't be surprised to learn that many (most?) STM32 "bare > metal" developers were caught by this. > > For the most part, the datasheets, user's guides, and/or reference > manuals are pretty darned good both in coverage and correctness. But it > sure would be nice if manufacturers included a "quick start" section > that mentioned all of the "oh by the ways."
Actually, for the F4's I've found that voluminous comments in the .c files for the peripheral drivers provide a lot of that. It took me a while to find them. Stuff like * =================================================================== * How to use this driver * =================================================================== * 1. Enable peripheral clock using the follwoing functions * RCC_APB2PeriphClockCmd(RCC_APB2Periph_USARTx, ENABLE) for USART1 and USART6 * RCC_APB1PeriphClockCmd(RCC_APB1Periph_USARTx, ENABLE) for USART2, USART3, UART4 or UART5. * * 2. According to the USART mode, enable the GPIO clocks using * RCC_AHB1PeriphClockCmd() function. (The I/O can be TX, RX, CTS, * or/and SCLK). * * 3. Peripheral's alternate function: * - Connect the pin to the desired peripherals' Alternate * Function (AF) using GPIO_PinAFConfig() function * - Configure the desired pin in alternate function by: * GPIO_InitStruct->GPIO_Mode = GPIO_Mode_AF * - Select the type, pull-up/pull-down and output speed via * GPIO_PuPd, GPIO_OType and GPIO_Speed members * - Call GPIO_Init() function * * 4. Program the Baud Rate, Word Length , Stop Bit, Parity, Hardware * flow control and Mode(Receiver/Transmitter) using the USART_Init() * function. * * 5. For synchronous mode, enable the clock and program the polarity, * phase and last bit using the USART_ClockInit() function. * * 5. Enable the NVIC and the corresponding interrupt using the function * USART_ITConfig() if you need to use interrupt mode. * * 6. When using the DMA mode * - Configure the DMA using DMA_Init() function * - Active the needed channel Request using USART_DMACmd() function * * 7. Enable the USART using the USART_Cmd() function. * * 8. Enable the DMA using the DMA_Cmd() function, when using DMA mode. * * Refer to Multi-Processor, LIN, half-duplex, Smartcard, IrDA sub-sections * for more details * * In order to reach higher communication baudrates, it is possible to * enable the oversampling by 8 mode using the function USART_OverSampling8Cmd(). * This function should be called after enabling the USART clock (RCC_APBxPeriphClockCmd()) * and before calling the function USART_Init(). for the USART. It's not always this good -- I'm fighting with I2C now. Mel.
On Sun, 22 Jul 2012 06:30:16 -0500, sburck wrote:

> Found it a while back and thought I'd come here and close this. All the > devices on this need to be given a clock, and I didn't give it one.
The TI/Luminary parts make that error easy to find by giving you a general bus fault when you try to access a peripheral that's not yet clocked. At least it's easier to find the _second_ time you run into it. In its way, quietly passing the thing over is just as bad -- but at least while you pull out the same amount of hair over the problem, you do so over a longer period. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
On Sunday, July 22, 2012 5:26:51 AM UTC-7, Rich Webb wrote:

> The lovely (ha!) thing about embedded processors is that quite often > missing just a single bit in an obscure register is enough to "break" > them. I wouldn't be surprised to learn that many (most?) STM32 "bare > metal" developers were caught by this.
Add me to the list. I'd never run across such a requirement before, even for GPIO pins.
Mel Wilson wrote:

>Actually, for the F4's I've found that voluminous comments in the .c files
>for the peripheral drivers provide a lot of that. It took me a while to >find them.
I'm right now porting my modestly large (~200K lines) bare-metal application to the F4. The current stage is reading all manuals and datasheets. Which example code did you excerpted that from? - Jonny --------------------------------------- Posted through http://www.EmbeddedRelated.com
Jonny Doin wrote:

> Mel Wilson wrote: > >>Actually, for the F4's I've found that voluminous comments in the .c files > >>for the peripheral drivers provide a lot of that. It took me a while to >>find them. > > I'm right now porting my modestly large (~200K lines) bare-metal > application to the F4. > The current stage is reading all manuals and datasheets. > Which example code did you excerpted that from?
It's from the firmware for the STM32F4-DISCOVERY board. http://www.st.com/internet/com/SOFTWARE_RESOURCES/SW_COMPONENT/FIRMWARE/stm32f4discovery_fw.zip Inside the .zip, look for Libraries/STM32F4xx_StdPeriph_Driver/src . I was quoting from stm32f4xx_usart.c . Mel.