topic Re: RS232 via SCI on DEMO9S08QG8 in 8-bit Microcontrollers

RS232 via SPI on DEMO9S08QG8

irob — Wed, 04 Apr 2007 22:56:12 GMT

Back in October 2005, Freescale had their rollout tour of the S08. I attended a seminar and got a Demo board. During one of the labs, they gave us a sample Codewarrior project which exercised the hardware SPI port, using the RS232 link to a PC. With a terminal app on the PC, you could work with the various features of the board, like PWM, the A/D, etc. Very nifty.

I finally got around to playing with this Codewarrior app for its SPI guts. I observed something strange. If I attempt to run this program from the board alone, I get nothing but garbage out the RS232 port, almost as if the parameters were slightly off (baud rate, parity, something). In the source code, it appears to come up natively in 4800 baud.

But when I run the app from the CW debugger, I get recognizable output on my terminal (using the excellent RealTerm, btw). Apparently, this is the only way to control the comm settings. I still don’t understand why it can’t be run from the board alone.

I’m guessing it’s because the crystal on the board (P/N FS12.00) isn’t a nice denomination of 4800. And apparently the debugger locks that in precisely? Is this correct?

Re: RS232 via SPI on DEMO9S08QG8

bigmac — Thu, 05 Apr 2007 11:07:52 GMT

Hello iRob,

Perhaps you might supply us with the contents of this sample project.

The 12 MHz crystal is associated with the processor for the BDM interface section - I don't think it is accessible by the target device. It would be reasonable to assume that the internal clock of the target would be utilised, and this would need to be calibrated.

On my QG8 demo board, there seems to be provision for an external crystal (32 kHz), but these components are not fitted.

Regards,

Mac

Re: RS232 via SPI on DEMO9S08QG8

peg — Thu, 05 Apr 2007 15:46:53 GMT

Hi Rob,

In your message and subject you keep talking about the SPI and then talk about RS-232 and baudrates, do you actually mean SCI and not SPI?

The QG8 demo board runs on internal oscillator unless you have fitted the crystal oscillator components into the empty positions on the board (and configured it to use the xtal). This internal oscillator needs to be trimmed for things that need a precise clock (like the SCI) unless you are very lucky and have a device that comes up close enough at the default midway setting.

Although I fail to see how having the BDM connected and active would assist in this.

The only explanation I can give is that you are failing to properly trim the internal osc and it is running at a frequency which is on the edge of being acceptable for SCI operation. Connecting the BDM somehow influences the frequency very slightly but enough to make it acceptable.

Re: RS232 via SCI on DEMO9S08QG8

irob — Thu, 05 Apr 2007 23:56:43 GMT

You are correct, Peg. I meant "SCI", not "SPI". Mods, can you change the original subject line to SCI? I'm unable to edit the first post.

And I think your theory is a good one, concerning the trim of the internal oscillator. I've never looked into trimming, so I'm not sure where to start. The P&E programming hardware handles trimming automatically, no?

I noticed in the QG8 datasheet that the ICSTRM register seems to handle trimming. Not sure yet how to initialize it.

Big Mac, I'm uploading the Freescale sample project for you guys.

Message Edited by irob on 2007-04-0510:58 AM

Re: RS232 via SCI on DEMO9S08QG8

peg — Fri, 06 Apr 2007 05:10:35 GMT

Hi Rob,

P&E's tools (in Codewarrior or not) will calculate and tell you the correct values for TRIM and FTRIM. You can then get it to programme these values to the places reserved for this purpose in flash. On a QG8 this is $FFAF for TRIM and $FFAE for Fine TRIM. On initialisation these should be sanity checked and copied to the working registers. In a S08QG these are ICSTRM $3A and bit 0 of ICSSC $3B.

Simple as that!

Re: RS232 via SPI on DEMO9S08QG8

thisobj — Fri, 06 Apr 2007 21:38:28 GMT

Hello irob,

I'm assuming that you're running the demo app unmodified. If so, internal clock trim is handled by the demo app and should not be an issue. One thing you might check is the jumper position on the "COM EN" option header. Unless an application is controlling the transciever via PTA4, this jumper should be removed. For this app, this jumper should be removed.

After verifying that the code runs in the debugger, halt the debugger, close the debugger, unplug the USB cable, then plug in the USB cable. The app should reset and you should see the menu displayed.

Terminal settings: 4800/8 bits/No Parity/1 stop/no flow control.

Good luck.

Frank

Re: RS232 via SPI on DEMO9S08QG8

irob — Mon, 09 Apr 2007 22:45:45 GMT

Thanks for the help, guys. I've got it running now stand-alone. There are some strange junk characters at the end of each line. But those may be RealTerm settings? I'm not sure. Take a look at the attached screenshot.

Re: RS232 via SPI on DEMO9S08QG8

Alban — Mon, 09 Apr 2007 23:58:24 GMT

Hi IRob,

Probably a page code translation error or a setting of Real Term to show the characters CR and LF.
Especially when both characters are understood properly because the menu displays fine.

Cheers,
Alban.

Re: RS232 via SPI on DEMO9S08QG8

peg — Tue, 10 Apr 2007 03:29:22 GMT

Hi Rob,

It is CR/LF. Because Realterm is more a diagnostic tool it shows everything. You can change the font to one they supply that actually has a little CR and LF and ACK etc rendered within each character.

I like to use Terminal Cntrl+Hex. I think it is a seperate download. This also allows you to "see" hex data.

Re: RS232 via SPI on DEMO9S08QG8

irob — Tue, 10 Apr 2007 03:48:35 GMT

Peg, any idea why the RealTerm Sourceforge page still has 1.99 (circa 2005) on it, while the I2CChip page has 2.0.0.43 from September '06?

Re: RS232 via SPI on DEMO9S08QG8

peg — Tue, 10 Apr 2007 13:38:56 GMT

Hi Rob,

No idea at all!

I have had some communication with the developer regarding some bugs and suggestions a long time ago and he pointed me in the direction of the other site.

Re: RS232 via SPI on DEMO9S08QG8

irob — Wed, 11 Apr 2007 04:22:57 GMT

thisobj wrote:
I'm assuming that you're running the demo app unmodified. If so, internal clock trim is handled by the demo app and should not be an issue.

Yes, I've not modified the demo app. And I see where the app is handling the internal clock with the function ics_intclk. But I'm not following how this sets up for a precise 4800 baud. That function sets the BDIV bits of ICSC2, and the clock source, but how exactly does that get accurately set to 4800?

peg wrote:
P&E's tools will calculate and tell you the correct values for TRIM and FTRIM. You can then get it to programme these values to the places reserved for this purpose in flash... On initialisation these should be sanity checked and copied to the working registers. In a S08QG these are ICSTRM $3A and bit 0 of ICSSC $3B.

The function ics_intclk does appear to instantiate the trim register:

volatile byte _NVICSTRM;

...where:

extern volatile byte _NVICSTRM @0x0000FFAF;
#define NVICSTRM _NVICSTRM

So the question is, how does this location get a trim value set? Is this were the P&E tools calibrate it?

Re: RS232 via SPI on DEMO9S08QG8

peg — Wed, 11 Apr 2007 13:14:10 GMT

Hi Rob,

$FFAF is where the programmer will put the trim value it calculates if you ask it to.

Here is the piece of code that moves it to the active register:

// Function for switching to an internal clock mode (FEI or FBI)
void ics_intclk(byte C1, byte C2) {
byte i;

if (NVICSTRM != 0xFF) {
ICSTRM = NVICSTRM; // load trim value if location not blank
}

This form of sanity check on the nonvolatile value is quite stupid even though it appears in most examples that I have seen. I actually prefer to do no sanity check (even though I said to do one before). The reason for this is.....

Failing to write to the trim register results in a value of $80, this value in a fair proportion of cases will result in a SCI that works and another fair proportion that will be marginal. The rest won't work due to baudrate mismatch. Writing an uninitialised value of $FF will result in a baudrate that never works which is far better than one that "sort of" works. This is because I have never seen a device that needs a trim value bigger thatn about $B0. Of course if you want to be fussy you could identify the un programmed non-volatile register and do something else to prevent it getting shipped. But blindly allowing the reset value to remain there is just asking for trouble.

BTW they are ignoring the fine trim here. It is not necessary as the main trim will get you close enough for correct SCI operation. Also I find that it seems to be beyond the ability of the BDM/software to calculate it correctly anyway.

Message Edited by peg on 2007-04-1104:17 PM

Re: RS232 via SPI on DEMO9S08QG8

bigmac — Wed, 11 Apr 2007 21:48:22 GMT

Hello Peg,

With respect to sanity checking of the oscillator trim value, in those cases where accurate trim is esential, I have even gone to the extent of inhibiting "normal" operation of the program, and have provided continuous flashing of an existing LED. This positively identifies that the trim value is unprogrammed, and hopefully prevents marginal products from reaching the field.

Regards,

Mac

Re: RS232 via SCI on DEMO9S08QG8

irob — Tue, 17 Apr 2007 00:00:33 GMT

Guys, this talk about the trim value being marginal in some microcontrollers has me worried. What do you do if it is? My goal is obviously to prevent any final assemblies from shipping with a marginal or non-compatible baud. That would defeat the whole point of doing the NRE for incorporating SCI (in my application). If these boards ever come back, this SCI app will be my only tool for troubleshooting its history.

Why wouldn't the BDM programmer put an accurate value into the trim register? I'm not understanding why this value would ever be marginal, provided I use that "sanity check" code Peg highlighted.

Re: RS232 via SCI on DEMO9S08QG8

peg — Tue, 17 Apr 2007 04:43:15 GMT

Hi Rob,

We are really just talking about ensuring that there was some value calculated and programmed rather than not at all. I have never experienced a variation in one device of more than 2 in the calculated trim (it does seem to vary with temperature a fair bit). That is why I say the fine trim is a bit hopeful using a BDM calculation (the LSB of the main trim varies by one every second time so why try to go any further).

Having said that I have never experienced a BDM calculated trim that does not produce a well within tolerance baudrate.

Re: RS232 via SCI on DEMO9S08QG8

irob — Wed, 16 May 2007 01:42:23 GMT

Hmm, I'm still not out of the water on this one. Though the DEMO9S08QG8_APP contains the trim code, I'm still having baud problems after programming.

Here's my repeatable test:

1) Program the DEMO board with Freescales's debugger from inside CodeWarrior. Click the Go button and the RS232 link works fine. Hit reset on the DEMO board or in the debugger and RS232 still works. Cycle power to the DEMO board and again, the RS232 still works.

2) Program the DEMO board with P&E's latest PROGHCS08 Programmer, v1.37. Now there is a trim problem, as the RS232 link is all garbled.

There has to be some setting that the P&E PROGHCS08 Programmer is not using, which the debugger is.

I've attached my program s-record. Can anyone else verify this behavior? It works on a DEMO9S08QG8 board.

Re: RS232 via SCI on DEMO9S08QG8

peg — Wed, 16 May 2007 05:12:42 GMT

Hi Rob,

Are you using the GUI or the command line version?

Are you issuing the PT command?

CW generates a script based on the menu settings. If you have selected calculate and program trim it will put a PT command in the script for the command line programmer to do.

Re: RS232 via SCI on DEMO9S08QG8

irob — Thu, 17 May 2007 00:25:54 GMT

I'm using the GUI version of P&E's programmer, PROGHCS08 Programmer. In the main window are a list of command line options, such as PM (program module), etc. See attachment. As you can see, there is no PT command. This is my problem, huh?

Can this command be added to the algorithm file, perhaps? Now curiously, I noticed that P&E's stand-alone programmer (Cyclone Image Creation Utility) does have the PT command. Weird.

Re: RS232 via SCI on DEMO9S08QG8

bigmac — Thu, 17 May 2007 03:02:26 GMT

Hello iRob,

It may be stating the obvious, but did you try scrolling down the command window - I seem to recall that, on some previous occasions, the program trim command was hidden from view. Another possibility is to enter "PT" from the keyboard, and see what happens.

Regards,

Mac

topic Re: RS232 via SCI on DEMO9S08QG8 in 8-bit Microcontrollers

RS232 via SPI on DEMO9S08QG8

Re: RS232 via SPI on DEMO9S08QG8

Re: RS232 via SPI on DEMO9S08QG8

Re: RS232 via *SCI* on DEMO9S08QG8

Re: RS232 via *SCI* on DEMO9S08QG8

Re: RS232 via SPI on DEMO9S08QG8

Re: RS232 via SPI on DEMO9S08QG8

Re: RS232 via SPI on DEMO9S08QG8

Re: RS232 via SPI on DEMO9S08QG8

Re: RS232 via SPI on DEMO9S08QG8

Re: RS232 via SPI on DEMO9S08QG8

Re: RS232 via SPI on DEMO9S08QG8

Re: RS232 via SPI on DEMO9S08QG8

Re: RS232 via SPI on DEMO9S08QG8

Re: RS232 via SCI on DEMO9S08QG8

Re: RS232 via SCI on DEMO9S08QG8

Re: RS232 via SCI on DEMO9S08QG8

Re: RS232 via SCI on DEMO9S08QG8

Re: RS232 via SCI on DEMO9S08QG8

Re: RS232 via SCI on DEMO9S08QG8

Re: RS232 via SCI on DEMO9S08QG8

Re: RS232 via SCI on DEMO9S08QG8