STM32F103 Blue pill - Scope on MCO pin

[jcfoto]

Hello.
Since several days (!) i try to obtain a signal on MCO pin ( PA8) on my blue pill board.
I'm using gcc-arm-none-eabi-10.3-2021.10-x86_64-linux from https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads + stlink tools + terminal window whithout any other librarie or IDE. All work perfectly with GPIO, timers, usart, clock management ...
For best clock management, i wish see Clock signal on MCO pin ( PA8) with a scope, without modify ( actualy !) the fault clock.

By fault, no signal appear. Fault clock is HSI ( internal 8MHz).
ST Doc is RM0041 §6 ( RCC) and 7 ( GPIO).
I use RCC_APB2ENR register ( §6.3.7 p 90), RCC_CFGR ( §6.3.2 p 80) and GPIOA_CRH  ( §7.2.2 p 112).
These registers works fine for others functions.

My code :

Code: [Select]

  //------------------  Define registers ( RM0041)
volatile uint32_t *APB2_ENR =   (uint32_t*)  0x40021018;
volatile uint32_t *RCC_CFGR =   (uint32_t*)  0x40021004; 
volatile uint32_t *GPIOA_CRH =  (uint32_t*)  0x40010804;


//Enable "alternate function". Bit 0 in RCC_APB2ENR
  *APB2_ENR |= (1 << 0);
  //Enable GPIOA. Bit 2 in RCC_APB2ENR
  *APB2_ENR |= (1 << 2);

//Enable PA8 as MCO - §7.1.4 p.103
  *GPIOA_CRH &= (0000<<0);      //RAZ PA8 ( input-analog)
  *GPIOA_CRH |= (11<<0); //PA8 output 50MHz
  *GPIOA_CRH |= (10<<2); //PA8 function alternative output Push-pull

       //Choose MCO entry - §6.3.2 p.80
  *RCC_CFGR &= 0xF8FFFFFF; //RAZ MCO pin config - bits 24, 25, 26
  *RCC_CFGR |= 0x04000000; //MCO = SYSCLK  ( = default HSI clock 8MHz)

Compilation and linkage are OK, and others functions in this programm on PA, PC, TIM3 and USART1 are working fine with these registers.
But ...  no signal on scope !
I've tried to alternatively pull-up and pull-down MCO pin with a 1K resistor without modification.

Have you an idea ?
Thank you for your tolerance about this bad english text !!!

[MK14]

Code: [Select]

  //------------------  Define registers ( RM0041)
//Enable PA8 as MCO - §7.1.4 p.103
  *GPIOA_CRH &= (0000<<0);      //RAZ PA8 ( input-analog)
  *GPIOA_CRH |= (11<<0); //PA8 output 50MHz
  *GPIOA_CRH |= (10<<2); //PA8 function alternative output Push-pull


At a quick glance, that doesn't seem right.

11, would mean eleven, not binary 11
Similarly, 10 is ten, not binary 10
Those zeros ((0000<<0), do you really intend to clear the entire register ?, or did you really want just a few bits of it.
Because AND'ing with 0, will zero the entire thing, not just a single bit.

https://stackoverflow.com/questions/15114140/writing-binary-number-system-in-c-code

[jcfoto]

Hi, MK14.
Thank you for help.
Sure, when i've began ''bare metal'', i had doubt. Now so !!! But since many experience, i've seen that this work on gcc-arm-none-eabi.
So, i've tested another code ( one time writing entire register ) with same issue :

Code: [Select]

  *GPIOA_CRH &= 0xFFFFFFF0; //RAZ PA8 ( input-analog) - bits 0,1,2,3
  *GPIOA_CRH |= 0x0000000B; //PA8 alternative function sortie 50MHz Push-pull -> 0b1011

have a nice day.

[MK14]

on my blue pill board.

I hope you don't mind me asking. But, is it an official blue pill board ?
Or might it be a Chinese cloned version.
Because the Chinese clone boards (e.g. bought on ebay), often have cloned versions of the MCU. Which, although they usually basically work and are reasonably compatible, with the original ST chip. They can have subtle differences, if you dig deep and start using rare/complicated things the real MCU would happily do.

I had to ask, because that could explain why many things are working out just fine as expected, but much rarer activities, is more likely to catch out cloned MCUs. Sometimes the cloned MCUs, have different part numbers, other times, they try and have the same markings as the real genuine ST MCUs.

[rcbuck]

Try this:
RCC_CFGR != 0x05000000;  // HSI clock selected
GPIOA_CRH |= 0x0000000B; // 50 MHz, AF

You do not need the GPIOA_CRH &= 0xFFFFFFF0 since the RCC_CFGR reset value is 0x00000000;

I am assuming you are not using the PLL as you don't show all of your configuration code. With the settings shown above you should see a 8 MHz signal on RA8.

If you are using the PLL at 72 MHz, change RCC_CFGR to RCC_CFGR !=0x07000000; The GPIOA8 pin cannot output a 72 MHz signal. That is why the PLL/2 option is there.

[jcfoto]

MK14 and rcbuck : i return with you this afternoon ( in Europe !).  I'll try rcbuck code and note marks of MCU, but my board is a recent chinese clone of Blue pill.
i'll write you later. Thanks for answers

[jcfoto]

MK14 : marks on MCU -> Usuals marks are present and ST logo is printed. But i keep your answer in my mind.
rcbuck : before bit registers modification, i prefer apply a reset of bits. It's, for me, a systematic rule ! Yes, for test, i'm using default  clock : HSI -> SYSCLK -> 8MHz without PLL.
I've tested your code ( use HSI and not SYSCLK) without other issue : no signal on MCO pin but it was a good idea.
Note that RM0041 fig 8 have error -> SYSCLK limitation is not 24MHz but 72MHz, as wrote in DocID13587 Rev 17 fig 2.
But this is independant of my init question !!!
Perhaps should i try to obtain this clock signal on mapple mini ( chinese !) or "Black pill" or other STM32F4xx ...

Have a good day

[rcbuck]

jcfoto, attached is a .bin file that you can load into the bluepill board. All it does is set the PLL to 72 MHz and all GPIO pins to push pull outputs. You will see 36 MHz on pin A8 with your scope or frequency counter. If you don't see 36 MHz, your board is defective. This code was written bare metal with no HAL involved. If you would like the source code I can zip up main.c and the two .h files and post them here.

You will have to change the file extension for zip to bin. The forum doesn't allow a bin file to be attached.

[jcfoto]

Yesssss ! rcbuck code work perfectly. I want the same !!!
A scope print-screen is in attachment.
And more, LED on board blink ...
So, i'll be very happy to see your code. Mine have an error !!!
Bare metal code is'nt an easy path and RM0041 have no example. For this, RM0090 ( STM32F4xx) is better.

nice to read you.

[rcbuck]

Source code is attached. I use STM32CubeIDE for my IDE. Place the zip file in a folder and unzip it. If you are using STM32CubeIDE just double click on the .project file. That should start STM32CubeIDE and import the project.

If you are not using STM32CubeIDE, just copy the main.c, main.h, and bm_gpio.h files into a folder in your development environment.

Good luck with your bare metal experimentation. The bare metal code is a lot smaller in size than the same project created using HAL. For example, the bin file for this project is only 880 bytes.

[jcfoto]

Thank you, rcbuck.  I work on yours files ( all are interesting !) and i return with you.

[jcfoto]

I've made a little cleaning in files cause of many overcoat "include" ...
So, i've a little code that works fine, without depandance :

Code: [Select]


*GPIOA_CRH = 0x0000000B; // GPIOA9-A15 all analog inputs (A8 output AF 50 MHz)

//72MHz -> HSE 8MHz - PLL x9
*FLASH_ACR |= ( 1<<3);
     //------ to do ----  USBCLK = 48MHz max --- diviser par 1,5
*RCC_CR |= ( 1<<16); // HSE on and selected as PLL input clock
while (!(*RCC_CR && (1 << 17))); //... attend le fonctionnement normal

*RCC_CFGR |= ( 1<<16); // HSE drives PLL with no division
*RCC_CFGR |= (0b100<<8); // APB1 prescale 2 -> 36MHz max

*RCC_CFGR |= ( 0b0111<<18); // PLL X 9 ( 8 MHz x 9 == 72 MHz)
*RCC_CR |= ( 1<<24); // Turn PLL on
while (!(*RCC_CR && (1 << 25))); //... attend le fonctionnement normal

*RCC_CFGR |= ( 0b10<<0); // PLL selected as system clock
*RCC_CFGR |= ( 0b111<<24); // MCO output is PLL output /2 (72/2 == 36 MHz)
For all clocks source, i've the good signal on MCO pin. Perhaps it was GPIOA_CRH that must be write in one time 32 bits ...
I've had an other error with the test of HSERDY and PLLRDY. My code work only with a compare operator ( &&) and not with affectation operator (&).
So, my problem have a good issue.
Just a point ( no critic) : with my code, your "pause" function don't work when PLL output is > 32MHz ( x4 ok, x5 false). I work on this.
Thank you very much for your most signifiant  help.
Jean

[jcfoto]

It's hawfull !  Since 3 years, i use, for STM32F103, the ST doc RM0041 witch is for STM32F100 ! The good doc is RM0008. In page 60, there is a field bits named "LATENCY" wich is the solution :

Code: [Select]

*FLASH_ACR |= ( 0b010<<0);   //2 wait cyclesFlash for 72MHz - RM0008 p.60

It was your line FLASH->ACR |= FLASH_ACR_LATENCY_2 ... that i couldn't understand on RM0041 !
Now, all is clear with your help.
Thank you very much.

[Siwastaja]

I'm all for "rolling your own", but do consider using the header files by the manufacturer. They include all the register addresses #defined for you. That's a lot of work to do manually with no gain at all, the result is the same. The headers define those registers as structs, but this is quite handy. So instead of *FLASH_ACR, you use FLASH->ACR (which is equivalent to (*FLASH).ACR)