Serial I/O

Replies to This Discussion

Permalink Reply by Eduardo Montanez on July 5, 2009 at 11:59pm

Hi ryan++, hope you had a good 4th of July weekend. Glad to see you are writing some code to configure the RS232 port.

Don't forget to configure the Pin Mux Controls:
The first thing that I would suggest you do to troubleshoot your software is to check that you have configured the MCF51CN128 pin mux controls properly to make the SCI1 [TXD1, RXD1] signals the function on those pins. Forgetting to configure the pins for that function or any other function happens all the time!! It bites me too!! Without configuring the pin mux controls, the pins remain to their default function. Refer to Section 2.3 Pin Mux Controls in MCF51CN128 Reference Manual to configure pin to appropriate alternate function. All pins default to Default Function out of reset.

MCU Clock Distribution and SCI Baud Rate Calculation:
Ok, now that we have gotten past that I see if my summary on MCU clock distribution to the SCI helps you properly calculate the baud rate. Figure 1-3. Clock Distribution Diagram from MCF51CN128 Reference Manual shows that the clock input for the SCI modules is MCGOUT clock. MCGOUT is also the input to CPU clock (aka core frequency). When you configure the SCI baud registers you need to understand the configured frequency for MCGOUT clock since it is the source for your SCI equations. Note that the MCF51CN128 device does not reset at the maximum core frequency allowed of 50.33 MHz. You have to configure MCG to achieve the maximum core frequency. Reset values for the MCG default to a much slower frequency out of reset. At a quick glance the MCG comes up in FEI (FLL Engaged Internal) mode where MCGOUT clock is derived from FLL clock, which is controlled by the internal reference clock. The MCG resets to low range DCO (Digital Controlled Oscillator) which is approximately 16-20MHz. Within the MCG there is a binary divider that resets to divide by 2. Therefore, MCGOUT clock defaults to between 8-10MHz. With the internal reference factory trimmed to 32.768KHz, MCGOUT should be close to 8.38MHz out of reset. If you want to achieve very precise SCI baud rates, I would recommend that you set the DMX32 bit to get very precise frequencies. Another way to achieve more precise frequencies is to switch to the external clock references on the board. Either the 32.768KHz or 25MHz crystal configurable through jumpers.

All good questions, keep them coming. I hope this helped somewhat. I'm going to see about writing some code of my own to initialize the TWR-MCF51CN on-board I/O on my spare time. :-)

▶ Reply to This

Permalink Reply by ryanplusplus on July 6, 2009 at 5:22pm

Thanks, Eduardo. That's rather helpful. I had found the right baud divisor through trial and error but could not figure out why the clock would have been anything but 50.33 MHz. I had also gotten pin MUXing figured out by looking at the bean for device initialization.

If I want to run at 50 MHz, can I just use the 25 MHz crystal on the board and use a multiplier or do I have to bring my own crystal?

▶ Reply to This

Permalink Reply by ryanplusplus on July 6, 2009 at 6:07pm

By the way, where can we get additional beans? They're rather helpful for learning since you can kind of deconstruct what needs to be done and work backwards to figure out what's really going on.

▶ Reply to This

Permalink Reply by Mitchell Thomas on October 19, 2009 at 7:56pm

I'm trying to do the same thing to develop some lab material for a class in the winter, and I'm stuck as to what I'm doing wrong. I understand what needs to be done, but something is still keeping it from working. Would you mind sharing your specific configuration code so I can check it against what I have?

Thanks for any help you can provide.

▶ Reply to This

Permalink Reply by John Mc on October 20, 2009 at 4:30pm

You can also post your code if you want and we can all take a look at it.

▶ Reply to This

Permalink Reply by Mitchell Thomas on October 26, 2009 at 4:10pm

ryanplusplus gave me a lot of help by pointing me to the Device Initialization wizard and walking me through it. I didn't even know it was available. All of the configuration information is in there, and it's pretty easy to read. After a little work, I was able to get it working. However, the serial communication is acting a little weird for me. Running just from the power-on reset, everything works exactly as I expect it to from my configuration, but in the OSBDM, the baud rate is wrong. Comparing the outputs from the two different situations using an oscilloscope, it looks like the OSBDM baud rate is about 10% too high. Does anyone have any ideas about this?

▶ Reply to This

Permalink Reply by Eduardo Montanez on October 30, 2009 at 10:41am

This sounds familiar, let me check my notes. I believe when you are running from debugger (using OSBDM) your SCI baud rate is off because you are using a different MCG trim value than when you are running from standalone mode. Let me get my head together from this cold I have and I will get you an answer. :-)

▶ Reply to This

Permalink Reply by Mitchell Thomas on November 2, 2009 at 11:39am

That seems to be spot on. I've tried unsuccessfully to find what the different trim values are. If you find out what the different values are, please let me know! I'll keep working on it. Thanks for the help.

▶ Reply to This

Permalink Reply by Eduardo Montanez on November 17, 2009 at 5:49pm

Mitchell,

Take a look at the ICSTRIM register in standalone mode versus in OSBDM mode. This would be a good place to start. I suspect this trim is set to different value in both these modes therefore slightly modifying your clock. You will have to set this value in software initialization to be consistent. If you use the external crystal I think this all goes away.

▶ Reply to This

Permalink Reply by Mitchell Thomas on November 17, 2009 at 9:32pm

Thanks for the advice. I meant to put this up a little while ago, but I got sidetracked with the end of the academic quarter. I solved the problem-at least for my specific configuration. First off, my professor did try this with the external crystal, and it worked exactly as expected. There were none of the OSBDM inconsistency problems. I took another route and wrote a little function to test trim values. My clock configuration code was coming from the Device Initialization wizard (I generated the code but just used it as a reference). I saw that the MCGTRM value was being pulled from a memory location and not hard coded. I placed this code in my function but hardcoded the MCGTRM register value based on an input to the function. After the clock was configured with a known MCGTRM value, I had it send out two characters on SCI2. The first character was 'G' (any character would work, I just needed to know which one it was), and the second was the MCGTRM value. In main, I ran a loop that called the function for 0...255. I received the characters on a terminal on my computer. Any MCGTRM value that worked would have a correctly received G next to it on the terminal screen. Using an ASCII table to decode the character into its decimal equivalent, I was able to find all the MCGTRM values that worked. Anything from about 170-190 worked, but I chose to use 180 for my code and it hasn't given me any issues since.