2
\$\begingroup\$

Firstly, yes I contacted ST for answers. Until now, no answer.

I'm using STM32F429 MCU and embedded USB FS PHY. To keep the 48 MHz USB PHY clock the maximum PLL clock that I can achieve is 168 MHz, unless the VCO clock is increased to 720 MHz. Then, I can achieve the PLL maximum frequency of 180 MHz and also provide the 48 MHz clock.

The datasheet says that the VCO clock should be on an interval of 100 to 432 MHz. Nevertheless, the same datasheet says that those conditions (100~432MHz) are valid for a source voltage of 1.7 to 3.3V.

Once my application always works at 3.3V, I've made some tests with VCO Clock at 720 MHz and everything worked!

Now, my questions are:

  1. Is it safe?
  2. Which tests should I run to verify the safety of this approach?

EDIT 1

No, it's not a hobby project. In fact, I'm trying to make some low-level performance improvements once the opcode has grown bigger and bigger since the first market release. Today it has 1.8 MB.

Anyone who has worked on a long-term project that has hundreds of thousands of lines of code knows that there are a lot of 'truths' or myths that are not entirely true. So, it's a good thing to question those from time to time.

By design, if a VCO can operate within a range of frequencies with a power source of X watts, it surely can operate in a bigger range with a power source of X + Y watts. Of course, components' saturations, and resonations must not be reached. How much? I do not know. Hopefully, ST experts know.

If ST would put into the datasheet all the information gathered during MCU design and rehearsal it would be unreadable. But, only because some information is not in the datasheet it not means that the information does not exist or it could not be true.

We are not mad to release something that still unclear, without all necessary tests.

Finally, I know that I'm going on an unknown path, that is the reason that I've come here. To hear some wise words from someone that has done something similar.

\$\endgroup\$
6
  • \$\begingroup\$ can you share a link to the datasheet you're referring to? \$\endgroup\$
    – The Photon
    May 3 at 17:21
  • \$\begingroup\$ @ThePhoton st.com/resource/en/datasheet/stm32f429ng.pdf pg 129, table 43. That table refers to table 17 on pg 95 \$\endgroup\$ May 3 at 17:55
  • 1
    \$\begingroup\$ You could run tests to see how much margin there is- will it work at 1GHz? How about 1GHz over temperature? But generally this is bad juju and will likely come back to bite with a new batch of chips or whatever. \$\endgroup\$ May 3 at 20:37
  • 1
    \$\begingroup\$ 168 vs 180MHz not a very big difference. Stop suing HAL and you will not need 180MHz anymore. \$\endgroup\$ May 4 at 12:22
  • \$\begingroup\$ @0___________ In fact, the application-performance test showed an improvement of ~ 60%. Over many trigonometric operations and external memory R/W we have to update the LCD. This is user sensible. We're able to go to a LCD frame update of 3.6 s. Before, it was at 6.1 s. \$\endgroup\$ May 4 at 16:01

2 Answers 2

7
\$\begingroup\$

Well, 720 MHz is 66% over the 432 MHz limit so highly unlikely it will work.

As you have correctly calculated, you can achieve 168 MHz as the highest core clock when 48 MHz USB clock is required. That configuration is guaranteed to work.

If you really need to run at 180 MHz instead of 168 MHz, and intend to overclock, then you have already selected the wrong MCU and patching that problem with something that is not guaranteed to work.

  1. Safe depends on what your MCU does and what happens if it does not work when you exceed specifications.

What you might just want to know if it will it work or not, and since you are exceeding specifications, it is of course not guaranteed to work. That is why the manufacturer gives out the specifications. The manufacturer will also likely say overclocking is unsupported by them and you are on your own if you try it and complain that it does not work.

  1. The point is not which tests you can run on your microcontroller that runs on your desk at 25 °C and at 3.300V. The point is will all microcontrollers from different batches, with different manufacturing tolerances, from other manufacturing plants, with other temperatures and supplied with other supply voltage will work at all.
\$\endgroup\$
8
  • \$\begingroup\$ I completely understand! But, yes! I'm running at 180 MHz (oscilloscope checked!) and my USB internal PHY is working too. By the formulas given, my VCO clock is at 720 MHz. So, my great doubt is: For a source voltage of 3.3V the voltage-controlled oscillator designed by ST is able to continuously provide 720 MHz? Sure, I comprehend that for a voltage ranging from 1.7 to 3.3V VCO output is guaranteed until 432 MHz. Nevertheless, for a voltage ranging from 3.27 to 3.4 V, which frequencies are guaranteed? \$\endgroup\$ May 3 at 18:05
  • 1
    \$\begingroup\$ @JonnyQuest So you say you understand but keep asking for something which can't be answered. If it does not read in a datasheet or reference manual then public information does not exist and unless you are a special customer you won't get the information privately from manufacturer either. So if you don't have a real reason to overclock, then don't. For a one-off hobby project, you can live as dangerously as you want. \$\endgroup\$
    – Justme
    May 3 at 18:42
  • \$\begingroup\$ It's difficult to say that something can not be answered if it was not asked. I have designed many VCO and I can say if it can operate at 432 MHz with a source of 1.7 V, it could operate at 720 MHz with a source of 3.3V. Of course, current must be provided, and no component must be saturated. For 3,3/1,7 = 1,94 and 720/432 = 1.67. If this community is only for information that is on hand, there's no meaning in the forum. \$\endgroup\$ May 3 at 18:58
  • 2
    \$\begingroup\$ @JonnyQuest But even if the the VCO works reliably like that, there is no guarantee that the rest of the IC will. I'm sure you know that you can't expect any guarantees when you move beyond the datasheet but you seem unwilling to believe that. You just have to run your own burn in tests on each individual part you are using. I don't know why you are asking for "guaranteed frequencies". The request is anachronistic to your requests for tests because if you had guarantees then you would not need tests. Look for tests that downhole equipment or space uses. \$\endgroup\$
    – DKNguyen
    May 4 at 15:27
  • \$\begingroup\$ I imagine you need to at least perform a 4 corner test and burn in for temperature and voltage with firmware that runs through all the parts of the MCU you plan to use and bin those that fail. And possibly also under simulated instabilities in voltage supply as well. That will require a hot/cold oven and a test rig. And then pull units from the production line and just leave them running 24/7. Probably not financially viable though since all you want from it is to match the PHY frequency. Downhole and space wouldn't qualify their components if they could get pre-qualified parts elsewhere. \$\endgroup\$
    – DKNguyen
    May 4 at 15:45
4
\$\begingroup\$

Is it safe?

No, it is not. If it is a hobby project run on your desk - you can experiment. But if you want to put it into the drone - never do it. In commercial projects - never do it. One of my friends did something very similar using AVR ATMEGA uC many years ago. He needed to implement 1-wire overdrive driver. AtMega was too slow and he had overclocked it. The company started to sell devices and eventually was overflowed by customer complaints.

Which tests should I run to verify the safety of this approach?

Such a test does not exist.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Of course you can design such tests. They would simple use many IC's, many, many hours of testing, and would be more expensive and time consuming than the asker has resources for. \$\endgroup\$ May 4 at 15:10
  • 1
    \$\begingroup\$ @ScottSeidman and you will test every single uC batch? You can test something but the test results will be meaningless. \$\endgroup\$ May 4 at 20:14

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.