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

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

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

ソリューションへジャンプ
988件の閲覧回数
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?

ラベル(1)
1 解決策
556件の閲覧回数
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!

元の投稿で解決策を見る

5 返答(返信)
556件の閲覧回数
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 件の賞賛
557件の閲覧回数
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!

556件の閲覧回数
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 件の賞賛
556件の閲覧回数
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 件の賞賛
556件の閲覧回数
Microfelix
Contributor IV

thank you very much. Now it works.

Maurizio

0 件の賞賛