EK-TM4C123GXL: Porting Clock Functionality from MSP430F5529

Hi Garrett,

Looks like you added an image since I first looked at the post.

For clock initialization, you won't want to use register level commands but rather a TivaWare API. Specifically, SysCtlClockFreqSet which is documented in this document in Section 26.2.2.2: www.ti.com/.../spmu298d.pdf

Hi Ralph,

I have shaped a timer example from TIVAware into a working prototype. I am currently using an 80MHz system clock and Timer 3 in PWM mode to output a signal to pin PB2 at 16kHz.

However, moving forward I would like to have Timer 3 operating at 4.096MHz, while the system clock remains at 80MHz, to produce a 16kHz PWM signal. I can't seem to find an API in driverlib that supports this division from the system clock. I have attached a snippet of my code for your reference.

Thanks,

Garrett 

Garrett Mize said:

However, moving forward I would like to have Timer 3 operating at 4.096MHz, while the system clock remains at 80MHz, to produce a 16kHz PWM signal. I can't seem to find an API in driverlib that supports this division from the system clock.

Where the PWM clock can be the System Clock divided by 1, 2, 4, 8, 16, 32 or 64 (PWM_SYSCLK_DIV_1,PWM_SYSCLK_DIV_2, PWM_SYSCLK_DIV_4, PWM_SYSCLK_DIV_8,PWM_SYSCLK_DIV_16, PWM_SYSCLK_DIV_32, or PWM_SYSCLK_DIV_64).

Given the clock tree restrictions, I think the closest you can get to the required clock configuration is:

    /* Set the system clock to run at 66.67 MHz off the PLL with external crystal as reference. */
    SysCtlClockSet (SYSCTL_SYSDIV_3 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN);

    /* Set the PWM clock to 4.17 MHz */
    SysCtlPeripheralEnable (SYSCTL_PERIPH_TIMER3);
    PWMClockSet (TIMER3_BASE, PWM_SYSCLK_DIV_16);

The PWM clock will be 4.17 MHz which is +1.7% higher than the ideal frequency of 4.096 MHz. Not sure if that frequency error will cause a problem for an audio application.

[I haven't tested the suggested clock configuration]

Ralph Jacobi said:

...TivaWare API. Specifically, SysCtlClockFreqSet

While not overwhelmingly clear - vendor poster is using "4C123" thus the "SysCtlClock" function must be chosen to support it - not the 4C129.

No mention is made of the required frequency accuracy - w/out that (key) guidance I offer the following"

• there are (now) "tunable oscillators" - which may be able to "dial in" to the chosen frequency  (likely add size and cost)
• firm/I have - on several occasions - "tested & binned" various xtals & xtal osc - which allowed a "better match" to the desired frequency.    (some consultation w/xtal vendor proves useful)   

What is the role of "4.096MHz" - such was unstated or my (multiple) reads "missed?"

As always - "abbreviated" details - delay & impede guidance... 

cb1_mobile said:

  Further - what is the role of "4.096MHz" - such was unstated or my (multiple) reads "missed?"

The PWM output is passed through a low-pass filter to build a DAC.

The rationale behind the 4.096 MHz PWM clock is that is 256 times the audio sampling rate of 16 KHz, such that with the PWM GPTMTnILR load value set to 256 the 8-bit audio sample value can be written to the PWM GPTMTnMATCHR match value.

Chester,

Thank you (rapid-fire & precise) becoming more & more your "trademark!"

While firm/I have "general awareness" of audio sampling rates - others may be chosen - IIRC even higher rates have taken hold @ "industry leaders."

The post provides NO target for accuracy, speed of response etc. - thus raises (many) questions...     (the use of the "tunable oscillator" requires (some) indication of  frequency accuracy demanded - and NONE was provided!)

Bruno Saraiva said:

In that case, would the application also need a 256 * 44KHz when playing at that higher resolution?

Bruno Saraiva said:

It's been ages since I played with MSP430's, but can they do such magic? Their master clocks are 16MHz and 20MHz if I'm not mistaken...

Bruno Saraiva said:

It is getting harder to generate a PRECISE 11.264MHz signal on a TM4C123...

1) For 8 bit audio at 16 KHz:

a) Set the TM4C123 system clock and PWM clock frequency to 80 MHz.

b) Set the PWM GPTM Timer n Interval Load to 5000 = 80 MHz / 16 KHz. This is an exact integer division.

c) Set the PWM GPTM Timer n Match to ((8-bit audio value) * 5000) / 256.

2) For 8 bit audio at 44100 Hz:

a) Set the TM4C123 system clock and PWM clock frequency to 80 MHz.

b) Set the PWM GPTM Timer n Interval Load to 1814 = integer value of (80 MHz / 44100 Hz). This generates a payback frequency of 44101.43 Hz or an error of +0.003%

c) Set the PWM GPTM Timer n Match to ((8-bit audio value) * 1814) / 256.

For 2c) and 2c) a 256-entry loop-up table could be created to give the translation from the 8-bit audio sample from the file into the value to write into the PWM GPTM Timer n Match register, to avoid the need to perform the re-scaling calculation on the fly.

All good & further information - time/effort/thought of "helpers" appears to have exceeded that of the originator.

Chester Gillon said:

MSP430 Frequency Locked Loop (FLL) allows the system clock frequency to be set to an integer multiple of a 32768 Hz crystal

Indeed this "Up-Scaling" of so low a frequency does provide a, "more granular end frequency."      But - that's not without trade-offs (perhaps warrants mention) - the most notable being any "change/shift" in xtal frequency - undergoes that (same) Up-Scale "Multiplication Factor" - creating the potential for "large" errors in frequency!    It too should be noted that any change in temperature, voltage, xtal aging - also will impact frequency accuracy and stability - again "magnified" due to that multiplication.  

"Real" frequency "standards" (i.e. precision oscillators - even those w/ "ovens") are thus far more likely to "Scale-Down" from a higher frequency - as the "Frequency Division" has the effect of "reducing" frequency error and/or drift - not "compounding" the error - as achieved via "multiplication."

Long ago (hopefully not continued today) top cabin Ham Receivers included a 100KHz (tweakable) oscillator - so that (some) secondary measure of frequency could be provided.     in the case of the 20 Meter Ham Band - that xtal freq. was multiplied by 140 (along w/any error/drift/other etc.) - which degraded frequency (accuracy & stability) by the extent of the multiplication...

cb1_mobile said:

Indeed this "Up-Scaling" of so low a frequency does provide a, "more granular end frequency."      But - that's not without trade-offs (perhaps warrants mention) - the most notable being any "change/shift" in xtal frequency - undergoes that (same) Up-Scale "Multiplication Factor" - creating the potential for "large" errors in frequency!  

cb1_mobile said:

It too should be noted that any change in temperature, voltage, xtal aging - also will impact frequency accuracy and stability - again "magnified" due to that multiplication.  

Chester Gillon said:

not all applications require the same frequency accuracy ... i.e.  replaying sampled audio, say a recording of speech, how much of a frequency error before the audio is no longer recognizable to a human listener?

Exactly!    And such was my (earlier) point re: "absence of the (needed) key specifications" - which (somehow) did not make it into originator's postings...   Note that (vendor) poster did provide certain "detail" but the bulk was outside the description of his central inquiring thrust.     (i.e. generating a frequency of adequate accuracy & stability - to yield "satisfactory" results.    (with "satisfactory" strangely undefined!)

Chester Gillon said:

1) For 8 bit audio at 16 KHz:

a) Set the TM4C123 system clock and PWM clock frequency to 80 MHz.

b) Set the PWM GPTM Timer n Interval Load to 5000 = 80 MHz / 16 KHz. This is an exact integer division.

Or set it to 255. That makes filtering the result a lot easier and preserves your 8 bit load. Then just reload at 16kHz. You do get a non integer number of PWM cycles per sample but the filtering may well mask that even though it's less than you would need for a 16kHz PWM. With the reduced filtering I would expect you might actually have improved fidelity.

Even so a 16kHz lookup wouldn't be especially difficult. For that matter a calculation to rescale the sample wouldn't impose much overhead.

Robert

Bruno,

I appreciate your honesty, this is also a new challenge for me and would not mind figuring it out with you. Audio playback is certainly the end goal. However, I am first striving to understand how to set up the clocks in a similar manner on Tiva to produce a simple PWM output. I am just having trouble understanding how to get Timer 3 to run at around 4.096MHz while utilizing a load value of 255 to get a 16kHz playback.

-WAV files are typically uncompressed audio files that have stored audio bit streams in PCM format (0's and 1's). The current MSP430 solution takes in an 8 bit segment of the .WAV at a time as a number and compares this "match value" to the "load" value. When match is hit, the output PWM signal is driven low until the next clock cycle/8 bits are loaded. A quick online search can provide in depth info if this is not sufficient.

-You are correct, PWM is the output which is passed into a low pass filter to produce sine wave audio. Yes the period would remain fixed, I am only interested in altering the duty cycle to change pitch, sound, etc. One 8 bit sample is taken over a full "load" count/period. This is the out put of the current code I provided.

-The MSP430 spi flash is loaded with sound files. The cpu then reads from the spiflash to provide samples to the CCR in the timer to produce a PWM output. I have not made it this far with the TIVA yet. I have been able to produce a 16kHz PWM output and vary the duty cycle manually, however this is with timer 3 running off the system clock (80MHz). I am trying to figure out how to configure timer 3 to 4.096MHz so that I may use a load value of 255 before I move forward with anything else.

Thanks,

Garrett

Bruno Saraiva said:

- What does a WAV file contain?

A wav file is just intensity vs time. If you displayed a microphone output on a 'scope, that's what the values in a wav file would look like.

Bruno Saraiva said:

- I'm assuming your output is a PWM signal, correct? Is the period fixed, varying only duty? Or are both variable? How frequent is the signal configuration changed (16000 times per second, or 16000 x 256 times per second?) Maybe you can sketch the output here? I'm sure these are obvious and basic information for you, and while several posters here have excellent knowledge about pushing TM4C timers to the limit, not many seem to meander onto sound domains...

Also what are you doing with the PWM? Are you filtering it and passing the filtered signal to an audio amp circuit or are you running a class D amp directly? Both would probably benefit from higher PWM frequencies but the details would matter.

Robert

Garrett Mize said:

-You are correct, PWM is the output which is passed into a low pass filter to produce sine wave audio.

What's your filter's frequency cutoff? (Given a 16kHz PWM, I'd hazard around 2kHz)

Robert

2703.PWM_DAC_Design.pdfHi Robert,

The output PWM is being pushed through a low pass filter and audio amplifier before output on the speaker. I have attached the reference design documentation which contains the parts used on the audio booster pack.

As I told Bruno I am simply using a logic analyzer at the moment on pin PB2 to look at the PWMs created on tiva. This is the pin that will eventually be used to output the signal to the booster back once the clocks are configured correctly.

Thanks,

Garrett

Garrett Mize said:

The output PWM is being pushed through a low pass filter and audio amplifier before output on the speaker. I have attached the reference design documentation which contains the parts used on the audio booster pack.

OK, an simple single pole RC low pass filter at ~3.7kHz (they're relying on the second stage to further filter).

I would ditch the 16kHz requirement. You will get less transmitted noise with higher PWM frequencies (the filter will be more effective). There's a small chance there could be some pickup but it's less than the chance that matching 16kHz will give problems and about the same that the micro's clock will cause pickup issues.

Overall, I can see no reason to keep 16kHz.

Robert

Bruno Saraiva said:

Does a wave file have some sort of standard header which tells what frequency it's been recorded at?

I believe so, I don't know a lot about the details but the format is documented somewhere on line I'm sure.

Bruno Saraiva said:

I believe that the optimum output frequency would be a influenced by:
- the filter characteristics and
- by what is a "reasonable" pwm setting with 256 evenly spaced levels to be managed by a 80MHz clock...

Pretty much. A simple RC filter such is on the board the OP is suing will be better at higher frequencies so from that perspective, the higher the better.

A PWM should reload automatically so no overhead there.

So first pass I'd set the PWM for an 8 bit duty cycle and just change the reload value at the sample rate. You could measure the distortion on a 'scope. I rather suspect the distortion introduced by the phase jitter in the output would be less than that introduced by using a 16kHz PWM.

We're only talking telephone line voice quality so the requirements aren't getting into audiophool territory.

Robert

Garrett Mize said:

I see your point. The 16kHz requirement stemmed from the customers desire to maximize memory space by having the smallest files possible. Hence, 16kHz was the lowest frequency that sounded acceptable.

A reasonable choice. Particularly if it's a noisy environment.

Garrett Mize said:

Do you think something like 22kHz would be better? They are not interested in CD quality playback, only simple voice playback.

Keep the sample rate the same. Just change the PWM frequency. That 3.7kHz filter limits your sound quality to voice in any case (and your board docs mention that).

The PWM frequency can rise to a few hundred kHz. I'd check that it can actually drive the filter to full range but I'd start with just a simple 8 bit duty cycle range and just let the frequency be whatever resulted.

Robert

80,000,000/256 ~= 312kHz

Garrett Mize said:

1. Is this method using the TM4C123G's PWM timer mode or the PWM module?

2. Would these two lines for the PWM clock be added in addition to my existing code or replace it? I believed I had already enabled Timer 3 and still would like for it to output on pin PB2.

As for use of the PWM timer mode .vs. the PWM module given that the design just requires single PWM output the PWM timer mode should be sufficient. The PWM timer mode can output on pin PB2 which on the EK-TM4C123GXL matches the PWM input expected by the TIDM-VOICEBANDAUDIO.

Based upon Robert's suggestions don't see the need for the PWM period to be 16 KHz  (the audio sample frequency). Instead:

1) Set the CPU clock frequency and timer module to the maximum of 80 MHz.

2) Use timer 3 with a PWM period set to 256 clocks.

3) At 16 KHz (the audio sample frequency) update the timer 3 PWM duty cycle using the next 8-bit audio sample value. The updates to the PWM duty cycle will be at approx 19.53 times the sampled audio rate which should help the RC filter on the board to remove the PWM harmonics.

By starting with a sampled 1KHz sine-wave you could compare the output against Figure 21. 1-kHz Sine Wave at 16-kHz Playback Frequency in the MSP430 based design.

When setting the PWM duty cycle you may need to offset the match value set to allow for either continuously low or continuously high outputs; see Figure 11-6. CCP Output, GPTMTnMATCHR > GPTMTnILR, Figure 11-7. CCP Output, GPTMTnMATCHR = GPTMTnILR and Figure 11-8. CCP Output, GPTMTnILR > GPTMTnMATCHR in the TM4C123GH6PM datasheet.

Garrett Mize said:

Do you think something like 22kHz would be better? They are not interested in CD quality playback, only simple voice playback.

If the audio files have already been recorded at 16KHz, I'd try and go to multiples of that. You'd simply be repeating the same PWM n times, with the benefit of less noise in the filter, but not increasing memory space... Maybe 64kHz?

If the audio files are to be recorded, then a more serious analysis would be needed: what is really an optimum analog value, versus the MCU capacity... But in this case, memory would grow accordingly.

*Like*

Chester Gillon said:

When setting the PWM duty cycle you may need to offset the match value set to allow for either continuously low or continuously high outputs;

Maybe not, it's audio, so no DC component. Clipping to remove the full on and full off values would likely not be noticeable.

Quite right that you'd need it for a 'full' solution but it may not matter.

Robert

Bruno Saraiva said:

If the audio files have already been recorded at 16KHz, I'd try and go to multiples of that.

I'd just go with the 8 bit sample size (or powers of two of it). Not much advantage to matching the PWM to the sample rate I think (remember there's a big low pass filter).

Bruno Saraiva said:

Maybe 64kHz?

I'm thinking 312.5kHz

Robert

In case it helps, I have just noticed that  TivaWare_C_Series-2.1.4.178 contains a driver in examples\boards\dk-tm4c129x\drivers\sound.c for generating sound on a DK-TM4C129X by using the PWM timer mode.

It may provide a suitable starting point for a driver on a EK-TM4C123GXL (I haven't checked sound.c for any TM4C129 specific TivaWare calls).