Receiving "ghost" data on UART RX, also writing to UART serial port 2 sends data on serial port 1

[tejada2]

I've recently taken over work on Netburner-based hardware. The code base that I'm working on has been moved from MOD5272 to MOD54415. Here are the problems or questions that I'm facing:

On MOD54415:

• My application is sending data on serial port 0 and serial port 2 at 19200 baud without any problem.

• On serial port 2, my application is receiving "ghost" data, i.e. data is not being sent to the UART, but the serial receive routine is being invoked.

• It's a mystery to me why the previous developer used serial port 2 for the MOD54415.

• I'm checking TX signals with an oscilloscope connected to UART 0 TX pin J2[4] and UART0 TX pin J2[22].

• QUESTION: Is there anyway via port control or selection bits that UART2 is mapped to the pins for UART1? I did not find anything in the MCF54415 documentation

• QUESTION: All control registers for UART2 are same as for UART0. What could cause "ghost" data to be received?

On MOD5272:

• My application is sending data on serial port 0 and serial port 1 at 19200 baud without any problem.

• I'm also checking TX signals with an oscilloscope connected to UART 0 TX pin J2[4] and UART1 TX pin J2[22].

• My application should receive data serial port 0 and serial port 1 without any problem, but haven't tested yet. Users have not reported any problems.

[TomNB]

Hello,

For the MOD54415, are you running on our development board or your own hardware? The mod-dev-70 maps uses the UART2 signals as GPIO for other circuitry, so that would interfere.

You mention registers. Did you write your own serial driver or are you using our API with the OpenSerial() calls? The 5272 has only 1 function per pin while the 54415 can have up to 4. So your serial driver cannot be the same as with the 5272.

Could it be that uart 1 was left open as a console port for status/debug messages?

We do offer extended support for 5272 migrations to any platform, including working directly with our engineering team to help with the port. It might be good to take advantage of that. You can start the process with a support ticket from your account, or if you do not have one, contact sales@netburner.com.

[tejada2]

Tom,

Thank you for your reply. Regarding my first question on UART2 mapped to UART1, this question has been resolved. We are using custom MOD54415 boards (NBSL-500IR, rev. 1.1, 2014/Nov) from NetBurner. So on the MOD54415, the UART2 TX, RX pins on J2[19], J2[31] have in fact been re-routed to where the UART1 TX, RX pins are on J2[22], J2[21].

We are using the OpenSerial() and CloseSerial() functions in NNDK 2.7.7. I'm not sure what the steps in and beyond the compiler are doing in terms of what actual OpenSerial() code version is linked in and executed. However, we are using the same code image for both MOD5272 and MOD54415, and I believe that are implementation in general is otherwise correctly addressing MOD5252 and MOD54415 differences with #ifdefs in the code.

I have already verified that the UART control registers UMR1n, UMR2n, USRn, USCRn, etc. are the same for the case that works on serial port 0 as the case that does not work on serial port 2. However, I have not yet done any checking on what the pin multiplexing setup is for pins [UART2_RXD / PWM_A3 / SSI1_RXD / PE4] and [UART2_TXD / PWM_B3 / SSI1_TXD / PE3].

I do have a MOD70 development board, but I have not yet run any standalone tests with a simplified case of opening, writing/reading and closing the serial ports. So far I have been trying to do the fixes in my application code.

I have also purchased an extended support contract, and I will make further contact with you via that channel.

Regards,
Mauricio