SCI datastream errors MC9S08GB60 vs. MC9S08GT16A

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SCI datastream errors MC9S08GB60 vs. MC9S08GT16A

754 Views
danielhembree
Contributor III

I have two different development boards, one is a M68DEMO908GB60 with a MC9S08GB60 micro, and another home brew board that has a MC9S08GT16A installed. I have written a simple program to transmit a three byte data packet about once a second via the SC1 port simulating a MIDI (musical instrument digital interface) message. I am able to monitor the raw data using a MIDI interface and a MIDI monitor utility running on a PC. The baud rate is configured at 31.25K and uses SCI1. The same is code running on the two different boards. While the messages are completely in tact from the GT16A home brew board, the data from the GB60 appears to periodically lose synch and produces an erroneous output in the monitor app. It is as if the bus clock is periodically changing and thus temporarily changing the baud rate. I have disabled the COP system thinking it may have been causing a system reset, but this has had no effect. Initially I thought the GB60 demo board might have a hardware issue causing the problem, but I have another completely different SBC that happens to utilize the GB60 and produces the same intermittent synch problem as the other GB60 board. I believe the GB60 and GT16A to be essentially the same core with only differences in available I/O. Am I missing something?

 

Thanks in advance for any input!

 

Dan

Labels (1)
Tags (4)
0 Kudos
Reply
3 Replies

571 Views
danielhembree
Contributor III

I probably should have included the following in my original post:

I am using Codewarrior IDE version 5.9.0

here is what I am initializing the micro with:

void SCI_init(void){

  SOPT_COPE = 0;      /*Disable COP             */

  ICGC1=0x038;        /*Bus Frequency is 4.19MHz*/

  ICGC2=0x00;

  SCI1BDH=0x00;       /* Set Baud             */

  SCI1BDL=0x08;       /* 9600=1a, 31.25K=08   */

  SCI1C1=0x00;        /*Clear SCI1C1 register */

  SCI1C2=0x00;        /*Clear SCI1C2 register */

  SCI1C3=0x00;        /*Clear SCI1C3 register */

  SCI1C2_TE=1;        /*Enable TX             */

  }

Thanks,

Dan


0 Kudos
Reply

571 Views
rocco
Senior Contributor II

Hi Dan,

Are you sure you disabled the COP? Might the SOPT register have been written prior to SCI_init?

Since the SOPT register is a write-once register, your "SOPT_COPE = 0;" line would have no effect if the SOPT register was written previously be the startup code.

0 Kudos
Reply

571 Views
danielhembree
Contributor III

Mark, thanks for the reply. I was not aware of the write-once behavior of the SOPT register. I see it now in the datasheet. There's a very good chance that this register is being written by the debugger prior to my access to it.

At any rate, I added a line of code that polls the SRS register for any flags set by interrupts but don't see any being generated. Additionally, I added a line that checks the SCI1S1 Status register for any other errors, but once again don't see any. I'm thinking about adding a buffer/line driver to see if its an issue related to driving the optocoupler in the MIDI interface I'm connecting to, though, the GT16A has no problem driving it.

0 Kudos
Reply