70F6, can't configure RCC for use with USB

[mike louaillier]

Posted on July 18, 2017 at 23:12

Hello i'm using CUBE 4.22 and i keep getting a conflict (see jpg bellow). when i click the checkbox USB->Device (FS), the TIM1 says ''!'' and shows several conflicts. and when i click on the Clock Configuration tab, the clock screen appears and i see a dialog box that says ''do you want to run the automatic clock issues solver?''. i click ''yes'' and then it says ''cannot find solution for some constraints''.

is there a way to resolve this problem? thanx

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[john doe]

Posted on July 19, 2017 at 01:19

>Is there a way to resolve this problem?

Its telling you that PLL MUX needs HSE not HSI. You need an external crystal/oscillator if you want to use USB.

[mike louaillier]

Posted on July 19, 2017 at 01:49

i don't understand. i specifically chose the 70xx chips because they're not supposed to need a crystal. the ST website says that

'The STM32F0x0... comes with a full set of performing peripherals, such as fast 12-bit ADC, advanced and flexible timers, and recently added crystal-less USB.'

but the data sheet for STM32F070xB and STM32F070x6 says that 'the clock source must use an HSE crystal oscillator'

but i have a nucleo board, the NUCLEO-F070RB, and programmed it with USB and it doesn't have a crystal. and the USB interface did work well.

so WTF? i don't have space on my PCB for a crystal.

and, i recall, i used CUBE to generate the code for the nucleo board. this doesn't make sense.

and when i go back to CUBE and click the Clock Configuration tab, the HSE option is greyed out, i can't select it.

thanx :)

OK (5 minutes later) i enabled the RCC with ceramic resonator and selected HSE. but the problem remains. i can't use a crystal and CUBE won't cooperate.

[john doe]

Posted on July 19, 2017 at 01:59

I'm just an inexperienced hobbyist. Perhaps its simply an oversight in the CubeMX application.

[mike louaillier]

Posted on July 19, 2017 at 02:02

so it seems. i hope someone out there will see this post who know how to work around this.

[john doe]

Posted on July 19, 2017 at 02:20

You could try generating the code as if it had an HSE, then just changing the generated code from RCC_OSCILLATORTYPE_HSE to HSI and PLLSource to HSI. Nothing says you can't change the generated code. It will just get clobbered if you re-generate.

8MHz (HSI or HSE) /1 (PREDiv) = VCOInput = 8 so far * 6 (PLLMul) = 48MHz which is what the USB needs

[mike louaillier]

Posted on July 19, 2017 at 03:17

yes that's a good idea i'll give it a try

[mike louaillier]

Posted on July 19, 2017 at 04:12

OK well i changed just a few lines of code:

  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;

  RCC_OscInitStruct.HSEState = RCC_HSE_ON;  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;

and it compiled and HAL didn't raise a hue and cry, so i think i'm good to go. thanx john :)

cubemx sysclk sysclock conflict hse hsi pllsource clock source internal 8MHz

[john doe]

Posted on July 19, 2017 at 04:34

lol thats the easy part.  does the chip run like that? that's the question!

[mike louaillier]

Posted on July 19, 2017 at 08:49

well i'm workin on the code now. tomorrow i'll see if it can blink an LED. problem is i don't know of any practicle way to check the sysclock frequency with just an LED. maybe there's a way to read the MCO....