RS232 via SPI on DEMO9S08QG8

[irob]

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?

[thisobj]

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

[irob]

---

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?

[peg]

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

[bigmac]

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

[irob]

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.

[peg]

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.

[irob]

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.

[peg]

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.

[irob]

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.

[bigmac]

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

[irob]

Ahh, good observation. I've snapped another grab with the program window bigger.

And as far as I can tell, the Programmer doesn't accept keyboard input like a command line would. I tried without luck.

I've submitted this question to the P&E forums as well. We'll see...

[peg]

Hi Rob,

Use the SA command to view the current s08 file.

Is there a line in there that contains TRIM (HCS08 TRIM or 09 BIT TRIM etc)

This tells the GUI to display the PT command, enable it and give it some parameters.

The s08 for QG8 I have is V1.00 9/14/05

You can use the keyboard to select commands but only the ones displayed

[irob]

Aha, eureka! Thanks, Peg.

Indeed curious. With all the various P&E programming products my company owns, I opened the following algorithm files I use for my target boards:

CodeWarrior debugger algorithms:
C:\Program Files\Freescale\CW08 V5.0\prog\P&E\9s08qg8.s8p
C:\Program Files\Freescale\CW08 V5.0\prog\P&E\9s08qg4.s8p

Cyclone Pro Rev B algorithms:
C:\Program Files\PEMicro\Cyclone_Pro\Algorithms\HCS08\9s08qg4.S8P
C:\Program Files\PEMicro\Cyclone_Pro\Algorithms\HCS08\9s08qg8.S8P

USB Multilink Rev B algorithms:
C:\Program Files\PEMicro\USBMultilink\Algorithms\9s08qg4.s8p
C:\Program Files\PEMicro\USBMultilink\Algorithms\9s08qg8.s8p

Curiously, the Multilink algorithms did not have those trim lines in the source. Both the Cyclone's and of course the Freescale debugger algorithms had the trim entries. So I just loaded up the cyclone algorithm instead and after reprogramming and then hitting the trim command option, my RS232 comm link now works!

It took two passes, because at first I assumed that the PT command would be automatic. But no matter, I know that with the Cyclone Pro Image Creation Utility, I can have the trim set automatically.

Thanks!

[irob]

Just an update. I contacted P&E and was sent privately a copy of the latest beta version of USB Multilink app. It's v 1.47 and includes the PT command.

[irob]

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.

[Alban]

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.

[peg]

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.

[irob]

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?

[peg]

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.

[bigmac]

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