No uart activity stm32f105

[stenasc]

Posted on June 30, 2014 at 10:32

Hi,

On our board which contains stm32f105R8, I can see no usart1 activity. I'ved used the supplied ST printf example to configure usart1. Our board has an external 8MHz crystal and I've seen it mentioned that the CL series expects an external 25Mhz crystal by default, so that may be the issue. I have set the XTAL clock value to be 8MHz in uVision4 tools hoping that would solve our problem but no luck. Does anyone have the correct settings for stm32f10x.h in order to use the external 8 Mhz crystal to generate a system clock of 48 Mhz? Thank you Bob

[Tesla DeLorean]

Posted on June 30, 2014 at 15:37

I'm not sure there are many using it in that fashion, so you're likely going to need to go through the PLL2 settings/configurations yourself.

STM32F10x_StdPeriph_Lib_V3.5.0\Libraries\CMSIS\CM3\DeviceSupport\ST\STM32F10x\system_stm32f10x.c TM32F105_107_AN3354_FW_V1.0.0\Project\STM32F105_107_IAP_USBHost\src\system_stm32f10x.c I'd suppose I could get 40 MHz (25 / 5 * 😎 from the example by using (8 / 2 * 10) or (8 / 4 * 20), or you could use HSE directly, and not use PREDIV1 And ensure HSE_VALUE is 8000000

[stenasc]

Posted on July 01, 2014 at 12:58

Thanks Clive

I tried (8 / 2 * 10)  to get 40 Mhz PREDIV2 =  /2 PLL2MUL = x10 and then used PREDIV1 = /5 PLLMUL =x6 HSE_VALUE is 8000000 I've changed the following code in system32f10x.c. Do I need to modify any other code? Cheers Bob

static void SetSysClockTo48(void)

{   __IO uint32_t StartUpCounter = 0, HSEStatus = 0;     /* SYSCLK, HCLK, PCLK2 and PCLK1 configuration ---------------------------*/      /* Enable HSE */      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 */     FLASH->ACR |= FLASH_ACR_PRFTBE;

    /* Flash 1 wait state */

    FLASH->ACR &= (uint32_t)((uint32_t)~FLASH_ACR_LATENCY);     FLASH->ACR |= (uint32_t)FLASH_ACR_LATENCY_1;          /* HCLK = SYSCLK */     RCC->CFGR |= (uint32_t)RCC_CFGR_HPRE_DIV1;           /* PCLK2 = HCLK */     RCC->CFGR |= (uint32_t)RCC_CFGR_PPRE2_DIV1;         /* PCLK1 = HCLK */     RCC->CFGR |= (uint32_t)RCC_CFGR_PPRE1_DIV2;     #ifdef STM32F10X_CL     /* Configure PLLs ------------------------------------------------------*/     /* PLL2 configuration: PLL2CLK = (HSE / 2) * 10 = 40 MHz */     /* PREDIV1 configuration: PREDIV1CLK = PLL2 / 5 = 8 MHz */               RCC->CFGR2 &= (uint32_t)~(RCC_CFGR2_PREDIV2 | RCC_CFGR2_PLL2MUL |                               RCC_CFGR2_PREDIV1 | RCC_CFGR2_PREDIV1SRC);     RCC->CFGR2 |= (uint32_t)(RCC_CFGR2_PREDIV2_DIV2 | RCC_CFGR2_PLL2MUL10 |                              RCC_CFGR2_PREDIV1SRC_PLL2 | RCC_CFGR2_PREDIV1_DIV5);       /* Enable PLL2 */     RCC->CR |= RCC_CR_PLL2ON;     /* Wait till PLL2 is ready */     while((RCC->CR & RCC_CR_PLL2RDY) == 0)     {     }            /* PLL configuration: PLLCLK = PREDIV1 * 6 = 48 MHz */     RCC->CFGR &= (uint32_t)~(RCC_CFGR_PLLXTPRE | RCC_CFGR_PLLSRC | RCC_CFGR_PLLMULL);     RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLXTPRE_PREDIV1 | RCC_CFGR_PLLSRC_PREDIV1 |                             RCC_CFGR_PLLMULL6); #else        /*  PLL configuration: PLLCLK = HSE * 6 = 48 MHz */     RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_PLLSRC | RCC_CFGR_PLLXTPRE | RCC_CFGR_PLLMULL));     RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLSRC_HSE | RCC_CFGR_PLLMULL6); #endif /* STM32F10X_CL */

    /* Enable PLL */

    RCC->CR |= RCC_CR_PLLON;

    /* Wait till PLL is ready */

    while((RCC->CR & RCC_CR_PLLRDY) == 0)     {     }

    /* Select PLL as system clock source */

    RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_SW));     RCC->CFGR |= (uint32_t)RCC_CFGR_SW_PLL;   

    /* Wait till PLL is used as system clock source */

    while ((RCC->CFGR & (uint32_t)RCC_CFGR_SWS) != (uint32_t)0x08)     {     }   }   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 */   } }  

[stenasc]

Posted on July 02, 2014 at 01:13 Hi Clive, I checked the various clock registers and they look to be fine. The USART1 looks ok too. However on stepping through the code, it hangs at the printf function. It occasionally outputs one rubbish character and then sits there. The retarget is pretty simple and is the same as was working on a f051 part. Bob PUTCHAR_PROTOTYPE {   /* Place your implementation of fputc here */   /* e.g. write a character to the USART */   USART_SendData(USART1, (uint8_t) ch);              /* Loop until the end of transmission */  while (USART_GetFlagStatus(USART1, USART_FLAG_TC) == RESET)         {}   return ch; }

[Tesla DeLorean]

Posted on July 02, 2014 at 02:28

I'd prefer to front test TXE, than wait on TC at the back. TC is prone to interference from the debugger sat viewing the peripheral. I guess TC has the benefit that the character reaches the terminal before following code crashes (though the machine keeps ticking in the background, might be important to wait for the USART to flush in power down or low power transitions, or changing baud rate or internal clocks)

PUTCHAR_PROTOTYPE
{
/* Place your implementation of fputc here */
while(USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET); 
/* e.g. write a character to the USART */
USART_SendData(USART1, (uint8_t) ch);
return(ch);
}

[stenasc]

Posted on July 02, 2014 at 08:34 Cheers Clive, I'll give this a go this evening and report back. I have a feeling it is going to be something more fundamental though. Bob

[stenasc]

Posted on July 02, 2014 at 23:17

Hi Clive,

It didn't work I'm afraid. I think there is something very fundamental going wrong here. I don't think the system is being configured properly on startup. The SysTick_Handler function isn't being called and this leads me to suspect that other interrupts say for controlling the uart aren't functioning. I can step through the code at the start of main() switching on LEDs, but it hangs at Delay(1000); I have a delay before I print out using the usart and I can't even get a delay using this SysTick_Handler. The reason I know it isn't being called is that I switch on an LED in this function. It never happens. Any basic setup checks that I can perform to help see what is happening? Many Thanks Bob

[Tesla DeLorean]

Posted on July 03, 2014 at 02:45

I suspect you probably want to go about printf() in Keil differently. I tend to use the semi-hosting route. Other ways might well end up hard faulting on an SWI instruction.

[DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Discovery/%C3%A8%20possibile%20usare%20printf&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F&currentviews=804]https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FSTM32Discovery%2F%C3%A8%20possibile%20usare%20printf&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F¤tviews=804

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Printf%20in%20Keil&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=2728

[stenasc]

Posted on July 04, 2014 at 23:45

Hi Clive,

I think our problem revolves around us having an incorrect crystal on the board. The CL series expects 25 MHz and we have an 8 MHz crystal on board. Changing the PLL multipliers and dividers doesn't really help we we are going to have to change the crystal. One thing that bothers me is that SysTick isn't working. I always believed that it was running on startup and all I had to do was configure the tick rate. This was the way on the previous micro. On the STM32F105 do I have to enable the SysTick interrupt on is it done by default? Many Thanks Bob

[Tesla DeLorean]

Posted on July 05, 2014 at 00:28

The SysTick configuration enables and sets the rate, there are other things to set the priority, and it's a system handler, rather than an interrupt per se.

You should be able to route clocks via the MCO pin (PA8) to confirm they are working. The original F10x design had some pretty restrictive PLL options, so really needed 8 or 4 MHz sources to work. you could get to 48 MHz via a 1.5 division of 72 MHz, and this magic occurs because the VCO clocks at twice the rate used, because it doesn't have the right duty cycle. There's no good way to get 25 MHz, and Ethernet needs that or 50 MHz, so you could get away with one clock source. If you don't have Ethernet, or your PHY has it's own clock, I don't see why the chip couldn't be used with an 8 MHz source. The F107 I have uses a 25 MHz, you'd have to send me a board with 8 MHZ if you wanted me to experiment.