K61 - UART4 - transmitted character being "echoed" onto the receive pin

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

K61 - UART4 - transmitted character being "echoed" onto the receive pin

Jump to solution
942 Views
gorakk
Contributor IV

Using CodeWarrior 10.3 and MQX 4.0.  K61FN1M0VJ12

I have a simple test program running - it transmits an "A" every 400ms on UART4.  The output looks good - either by looking at it with a scope or viewing on a terminal program on a PC. But, checking RX4 with a scope shows the same transmitted character is present there.

Our BSP and program use the UARTs in interrupt mode.

We have eliminated the possibility that the echo is happening externally to the K61. A bare metal program written with the Keil tools does not have this problem - characters transmitted on TX4 do not show up on RX4. Also, the trace connecting RX4 to the rest of the system was cut as a test as well.

There is a register setting that can put the UART into a loopback mode but register UART4_C1 is 0x00 and this has been verified using the debugger.

I'm not seeing this behavior on the two other UARTs being used - UART2 and UART5.  I've compared UART4 and UART5 registers that have anything to do with UARTs but have not found any major differences.

Does anyone have any suggestions on where else to look?

Labels (1)
1 Solution
510 Views
gorakk
Contributor IV

It turned out that in our BSP for our custom board we had missed these lines in __pe_initialize_hardware() - they change the MUX for the pins to EXTAL1 and XTAL1:

/* PORTE_PCR24: ISF=0,MUX=0 */

PORTE_PCR24 &= (uint32_t)~0x01000700UL;

/* PORTE_PCR25: ISF=0,MUX=0 */

PORTE_PCR25 &= (uint32_t)~0x01000700UL;

Our oscillator is connected to EXTAL0 (PTA18) and XTAL0 (PTA19).

Even though our application project was subsequently changing the pin MUX to UART4 TX and RX we still had the problem described above.

After commenting out the above lines UART4 is working properly.

Thanks to Mike and David from Freescale for their help with this!

View solution in original post

5 Replies
510 Views
georgerouse
Contributor II

Section 5.2 of application note 4526 explains why disabling OSC1 fixes the problem:

5.2 Oscillator (OSC)

A second oscillator has been added (OSC1). The new OSC pin functions are muxed over PTE24 and PTE25, so if the second

OSC is used it will impact hardware if any of the functions on PTE24 and PTE25 were being used.

OSC1 can be used as an input to the MCG, so the addition of the second OSC does affect the MCG module. Refer to the

MCG section for more information.

0 Kudos
511 Views
gorakk
Contributor IV

It turned out that in our BSP for our custom board we had missed these lines in __pe_initialize_hardware() - they change the MUX for the pins to EXTAL1 and XTAL1:

/* PORTE_PCR24: ISF=0,MUX=0 */

PORTE_PCR24 &= (uint32_t)~0x01000700UL;

/* PORTE_PCR25: ISF=0,MUX=0 */

PORTE_PCR25 &= (uint32_t)~0x01000700UL;

Our oscillator is connected to EXTAL0 (PTA18) and XTAL0 (PTA19).

Even though our application project was subsequently changing the pin MUX to UART4 TX and RX we still had the problem described above.

After commenting out the above lines UART4 is working properly.

Thanks to Mike and David from Freescale for their help with this!

510 Views
Microfelix
Contributor IV

hello

I too have the same problem but on the K70.

I tried to comment the lines you suggested.

But to me it does not work.

Should I do anything else?

Maurizio

0 Kudos
510 Views
gorakk
Contributor IV

Maurizio,

I had also commented out another line in __pe_initialize_hardware() - I wasn't sure that it mattered so I didn't include it the fix that I posted.

//OSC1_CR = (uint8_t)0x80U;

Does commenting out this line and then rebuilding your BSP make a difference for your project?

Allen

0 Kudos
510 Views
Microfelix
Contributor IV

thank you very much. Now it works.

Maurizio

0 Kudos