Main clock + Simulation EEPROM

[Birdo]

Posted on November 04, 2015 at 08:38

Hi,

I just started to pickup programming STM32F0308-DISCO based on 

STM32F030R8T6.

I have configurated the clocks and got the timers working on the desired 48 MHz. But when I try to simulate a delay with a for loop in the main function I noticed that the clock speed is less than 48 MHz with the code:

uint32_t i =0;

for(i = 0; i < 48000000; i++)

It gives a delay of around 15 seconds. I thought SYSCLK is the speed of the main function, which I configurated on 48 MHz. Am I getting this wrong?

Next question is about the simulation of EEPROM memory in the flash registers. The 

STM32F030R8T6 uses 64 kbytes flash on registers 0x0800 0000 - 0x0800 FFFF. When I write on page 63, starting on 0x0800 FC00, everything works. It writes the flash register and when I read it I get the desired value. But when I program it again, the system keeps getting stuck when erasing the page.

FLASH_SetLatency(FLASH_Latency_1);

FLASH_PrefetchBufferCmd(ENABLE);

FLASH_Unlock();

FLASH_ClearFlag(FLASH_FLAG_EOP | FLASH_FLAG_PGERR | FLASH_FLAG_WRPERR);

FLASHStatus = FLASH_ErasePage((uint32_t)0x0800FC00);

FLASHStatus = FLASH_ProgramWord((uint32_t)0x0800FC00, 0x12345678);

FLASH_Lock();

Looking forward to your comments.

Regards

[Danish1]

Posted on November 04, 2015 at 12:23

48 MHz is the speed at which the arm processor executes (simple*) machine-code instructions. I am not surprised that the for loop compiles into more than one machine-code instruction.

Telling your compiler to optimise the code should make things faster.

*more complicated machine-code instructions can take more than one processor cycle to complete.

I'll let someone else deal with your FLASH issue.

Hope this helps,

Danish

[Tesla DeLorean]

Posted on November 04, 2015 at 14:01

15 cycles seems a bit high, are you using a GNU/GCC compiler? Each iteration is going to be more that a single machine cycle, the loop would take several even in assembler.

Do you look at the returned status from the flash commands, might tell you something? Does it end up in the Hard Fault Handler? Have you step through with a debugger? What did you learn?

Take a look at FLASH->SR

[Birdo]

Posted on November 05, 2015 at 08:31

Ok thank you guys for the main speed issue. It makes sense to me now.

Writing the simulation EEPROM in Flash also works at the moment. But this happened accidently when I was setting up the USART. When I printf some text before the first page erase it doesn't get stuck. When I remove the printf text it gets stuck again. The only thing I changed in the printf file is:

void PrintChar(char c)

{

/* Send a char like: 

  while(Transfer not completed);

  Transmit a char;

*/

USART_SendData(USART2, (uint16_t) c);

    while (USART_GetFlagStatus(USART2, USART_FLAG_TC) == RESET);

}

Is there a clear reason for this behaviour?

Regard