3
\$\begingroup\$

A board with STM32F103C8T6 sometimes runs into hard fault handler.

When I heat up the board to 65C or higher, a hard fault will be caused randomly, which leads me to check if the latency of the flash is not enough.

Then I set the flash latency to 1 clock, the problem is solved,the chip runs stably even when I heat it up to 100C.

But it makes no sense because CPU runs at 24MHZ(HCLK is 24MHZ), which means no flash latency is needed as the datasheet says.

Here are my detailed clock configuration: Clock source is 16MHZ given by external crystal, and PLL is 3x(I need to use USB ,so a clock of 48MHZ at SYSCLK is needed), then the AHB prescaler is configured to 2, so the clock of the CPU is 24MHZ.

I looked up the datasheet and it doesn't say clearly where the flash is clocked, but it says "Flash memory instructions and data access are performed through the AHB bus", does it mean the clock of the flash equals to AHB (24MHZ in my application)? But it doesn't work stably, where am I wrong?

Thanks

\$\endgroup\$
  • \$\begingroup\$ You might want to link us to the datasheet, its quite easy to get outside the SOA on high temperatures since certain parameters can be derated. Also, how do you heat up the board? externally? or via burning up cycles in the cpu (which could mean a much higher junction temp) \$\endgroup\$ – PlasmaHH Sep 30 '16 at 14:03
  • \$\begingroup\$ The temperature of the CPU is represented by the internal temperature sensor, I think it is exactly the temperature inside the chip. \$\endgroup\$ – user123179 Sep 30 '16 at 14:22
  • \$\begingroup\$ For computing clocks (and related settings) ST's CubeMX is a great tool - even if you use Standard Peripheral Library instead of Cube HAL. It clearly shows clock relationships and can generate clock init code (although that's for Cube only). \$\endgroup\$ – Jan Dorniak Sep 30 '16 at 17:41
8
\$\begingroup\$

The description of the Flash access control register (FLASH_ACR) (Page 59 of the manual here) states:

Bits 2:0 LATENCY: Latency
  These bits represent the ratio of the SYSCLK (system clock)
     period to the Flash access time.
  000 Zero wait state, if 0 < SYSCLK≤ 24 MHz
  001 One wait state, if 24 MHz < SYSCLK ≤ 48 MHz
  010 Two wait states, if 48 MHz < SYSCLK ≤ 72 MHz

So it looks like the flash is referenced to SYSCLK which you have at 48MHz.

\$\endgroup\$
  • \$\begingroup\$ You might want to add <!-- language: none --> before the code block to get rid of the confused syntax highlighting. \$\endgroup\$ – jms Sep 30 '16 at 14:13
  • \$\begingroup\$ Done. It looks like it's <!-- language: lang-none --> for no highlighting. \$\endgroup\$ – Andrew Sep 30 '16 at 14:20
  • \$\begingroup\$ Thank you and it seems right, but it is still somewhere confusing. A much higher frequency of flash is not necessary when CPU is clocked slowly, flash clocked by SYSCLK seems not like the best design. \$\endgroup\$ – user123179 Sep 30 '16 at 14:29
  • 1
    \$\begingroup\$ Flash has to be clocked by sysclk if you ever want to access it with single-cycle latency. \$\endgroup\$ – pjc50 Sep 30 '16 at 14:33
  • 1
    \$\begingroup\$ Any reason why a code block was used here instead of a quote block? The syntax highlighting on mobile devices is odd and it doesn't make sense that a quote would be a block of code. \$\endgroup\$ – Kevin Brown Sep 30 '16 at 17:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.