0
\$\begingroup\$

I'm trying to configure system clock in the TIVA TM4C123g board. I'm aware that this clock signal goes to a pin called OSC0 which, according to this, is the pin number 41 (see page 22). According to the same document, that pin is supposed to be in the PCB's U1 module, which can be found in Component Locations.

I have found the module in my board:

this.

However, there are no debug pins connected to it. Am I supposed to measure directly the pins that come out from the chip? Isn't it dangerous? (you could touch two of them with the probe, causing a short).

How can I measure the system clock frequency so I can be sure I have configured it correctly?

\$\endgroup\$
  • \$\begingroup\$ You need to locate the schematic diagram for your circuit board. \$\endgroup\$ – Andy aka May 30 at 14:39
  • \$\begingroup\$ @Andyaka FYI the question has contained a link to the schematic from the start, but the asker has misread it. \$\endgroup\$ – Chris Stratton May 30 at 17:34
1
\$\begingroup\$

You have misread the schematic which you linked.

The part you have circled is actually U2, the debug interface comprised of an additional MCU, with its own clock circuit, while U1 is the target MCU placed in diagonal orientation in the middle which runs your program.

While some similar boards save a little money by feeding a clock output from the debug MCU to the target, the schematic you linked shows that yours does not.

Rather, on your board, the target U1 is clocked from its own external 16 MHz crystal, or a lower frequency watch crystal, or likely internal oscillators, likely starting from the latter and then shifting to another option under software control. More importantly, in common usage it would actually not be directly clocked by these, but rather by the output of an internal PLL multiplier configured by your code.

Generally speaking, if you perform the right configuration options (ie using a vendor library) and do not do something unexpected (like call the configuration routine when it is already running on the PLL) these "just work" and you typically would verify that they are operating by reading status bits with software.

If you really wanted to look at the external clock frequency with a scope, try probing C32 or maybe C31 with a 10x probe to minimize disruption of the circuit. Generally though it would be better to configure some clock-dependent output and measure the frequency of that - a very obvious case being a serial UART you want to use for debug messages anyway, or perhaps a timer peripheral. Typically this is also downstream of the PLL, though clock trees on modern MCUs can be rather complex.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Please can you give me more details about measuring a clock-dependent output? I don't see how to measure the clock frequency through the UART \$\endgroup\$ – Martel May 30 at 22:28
  • 1
    \$\begingroup\$ With a UART you would transmit something like 0x5A that has a lot of bit transitions in a tight eternal loop, look at the signal with a scope, and see if the baud rate is as expected. Since the baud rate is divided from a clock this lets you determine the frequency of that clock. Of course it might be a peripheral clock which may have some small ratio relationship to whatever sources the core clock. Again, you probably do not need to "measure" this - what makes you think it is wrong? \$\endgroup\$ – Chris Stratton May 30 at 23:56
  • 1
    \$\begingroup\$ Why do you ultimately even care what the clock is? If you have an answer to that, then the reason for your concern is likely to suggest the best clock to measure and method of measuring it. \$\endgroup\$ – Chris Stratton May 30 at 23:58
  • \$\begingroup\$ Actually I'm trying to configure and use a PWM (which of course doesn't work) and I suspect that the problem might be the clock signal it is receiving \$\endgroup\$ – Martel May 31 at 0:07
  • 1
    \$\begingroup\$ You need to make sure the timer producing the PWM and probably the GPIO bank it would come out through are both clocked and configured. If they are clocked but clocked at the wrong rate then you'll probably get PWM at a different frequency than desired, and from that you could deduce the clock issue. Why don't you start with some known good PWM example and then gradually migrate it towards your specific need? \$\endgroup\$ – Chris Stratton May 31 at 1:04
1
\$\begingroup\$

The processor you circled is part of the debugging interface. It is not the processor that you can program. The processor that you can program is the one shown below, mounted at an angle.

The debug processor implements the USB interface for this Launchpad board, so changing its clock frequency is likely to break the USB communications.

| improve this answer | |
\$\endgroup\$

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.