SCI and BDM problems - works without BDM, doesn't work with BDM - 9S12XA256 and 9S12DP512

[paulcsf]

We have recently run into a new problem. When trying to debug with Codewarrior and the BDM, the SCI port doesn't work correctly. We have tried this with two or three BDM modules, 3 or 4 different boards, and two computers.

The problem:

When the code is run from the Codewarrior debugger with the BDM, the SCI port doesn't work. We have narrowed it down to enabling the receiver, SCI0CR2_RE. With this separated out to a single instruction, SCI0CR2_RE=1; the RXD pin is pulled low, actively pulled low, not just a weak pull down. Depending on the situation, this causes the RXD line to sit at 0.25 - 1V, instead of the ~3.3V it should be.

The first scenario:

We have a new C project, which works fine when run without the BDM, or when run in the emulator. When run from the debugger with the BDM, the SCI port doesn't work. This code and target board are new, but modeled after long running products.

The second scenario:

We have a large code base of existing assembly code. This code runs fine by itself, but when started from the debugger with the BDM, the SCI port shows the same behavior. I can't single step through the code, the BDM loses track when writing some of the ports, when switching the clocks, etc. This code and target board have been shipping for a number of years.

And the details:

Codewarrior 4.7

9S12XA256 (1M84E)

9S12DP512 (0L15Y)

Two different target boards

I checked the errata for both masks, and don't see anything. This only happens if the debugger is used to step through or start execution. If I power up the board, even with the BDM module attached, everything is just fine.

Has anybody seen similar issues? Any ideas?

Added p/ns to subject.

Message Edited by NLFSJ on 2009-06-10 03:44 PM

[kef]

Since SCI RDRF, OR, NF, FE flags are reset by reading status register followed by reading data register, BDM debugger data window should be not pointed to SCI registers. Because BDM debugger may refresh data windows (periodically or after single step) and read and reset SCI flags. Of course code may get broken. Isn't this your case?

We have narrowed it down to enabling the receiver, SCI0CR2_RE. With this separated out to a single instruction, SCI0CR2_RE=1; the RXD pin is pulled low, actively pulled low, not just a weak pull down. Depending on the situation, this causes the RXD line to sit at 0.25 - 1V, instead of the ~3.3V it should be.

Isn't something external like RS232 level shifter driving RXD pin?

9S12DP512 (0L15Y)

0L15Y is 9S12XDxxx maskset.

Could you reduce your code to minimalistic set of routines that work without BDM and don't work with BDM, and post here?

[paulcsf]

The mask set/part number is a typo, you are correct, it's a 9S12XDP512, mask 0L15Y.

As for the pin level, that's what is so bizarre about this problem. Yes, an external device should be driving the pin. On some of the target boards it's an on board RS232 level shifter, and some target boards have the level translation done externally. In both cases, the micro is pulling the RXD line down to the point where the data isn't received because it doesn't exceed the threshold voltages.

This isn't related to the status registers, as it's long before we would even worry about the status registers. This is in the init code, and single stepping through the C code, everything is fine, enable the receiver, and the RXD pin is pulled low. That state doesn't change until the processor's power is cycled.

[paulcsf]

Here is the SCI init function, again this works just fine when run in flash by itself, and runs just fine in the hardware emulator, but when debugging with the BDM from Codewarrior, it goes haywire.

static void __near init_sci1(uint16_t sci_sbr, uint8_t sci_mode){    /* SCI1BD - SCI1 Baud Rate Register       15: IREN = 0: infrared disabled;       14-13: TNP = 0: IR pulse width (irrelevant)       12-0: SBR12-0 SCI baud rate = bus clock / (16 x SBR[12-0]) */    SCI1BD = sci_sbr;     /* SCI1CR1 - SCI1 Control Register 1       7: LOOPS = 0: normal operation;       6: SCISWAI = 0: SCI enabled in wait mode;       5: Rsrc=0: only relevant for loop (bit 7) operation;       4: M = 0: 8 data bits;       3: WAKE = 0: idle line wakeup;       2: ILT = 1: idle char bit count begins after stop bit;       1: PE = 0/1: parity disabled/enabled, depends on setting;       0: PT = 0/1: parity even/odd, depends on setting */    SCI1CR1 = sci_mode | SCI1CR1_ILT_MASK;     /* SCI1DRH - SCI1 Data Register High1       7: R8 = x: received bit 8 (write meaningless);       6: T8 = 1: transmit bit 8 set to 1 */    SCI1DRH = 0xFF;     /* SCI1CR2 - SCI1 Control Register 2       7: TIE = 0: transmit interrupt disabled;       6: TCIE = 0: transmit complete interrupt disabled;       5: RIE = 1: receiver full interrupt enabled;       4: ILIE = 0: idle line interrupt disabled;       3: TE = 1: transmitter enabled;       2: RE = 1: receiver enabled;       1: RWU = 0: normal operation (RWU disabled);       0: SBK = 0: normal break characters */    SCI1CR2 = 0x2C;}

We have tested breaking the SCI1CR2 = 0x2C; instruction down to SC1CR2 = 0x28; and SCI1CR2_RE=1; and it's definitely the receiver enable.

Any thoughts?

[kef]

It seems SCIDRH register bits 6 to 0 have some undocumented function in special mode. I also get RX pulled low in special mode, when I write 0xFF to SCIDRH. Maskset 0L15Y.

Try keeping bits bit6 to bit0 of SCIDRH cleared.

Would be nice if you did service request for this.

Message Edited by kef on 2009-06-11 09:22 AM