> 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?
>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
Reply by ●July 23, 20122012-07-23
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.
Reply by Tim Wescott●July 22, 20122012-07-22
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
Reply by Mel Wilson●July 22, 20122012-07-22
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.
Reply by Rich Webb●July 22, 20122012-07-22
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
Reply by sburck●July 22, 20122012-07-22
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
Reply by Tim Wescott●July 3, 20122012-07-03
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
Reply by sburck●July 2, 20122012-07-02
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