I've been trying to set up a second serial port on the Mistral DM8148 eval board.
I have identified UART4 and UART5 as candidates because the MUX'ed pins do not conflict with anything else I need.
UART4 is the best choice because it has an RS232 level shifter and is wired to the RTS/CTS pins on the "UART" connector on the application board.
Using this setup I have been able to transmit via UART4, but I cannot receive any data. I have learned a lot about the DM8148 and the
eval board, but apparently I am still missing something.
The receive logic level coming out of U26P10 (the RS232 level shifter on the applications board)
is stuck at logic 0. It should idle at logic 1 and go low only while characters are being received.
The input to the IC at pin 9 has the correct RS232 receive signal. It seems like something else
on the base or applications boards is shorting the signal to ground, but I see nothing in either
schematic that would ground the signal.
To review, my plan is to set up the MUXMODE registers to replace the UART0_RTSN and UART0_CTSN
signals going to the DB9 "UART" port of the application board with the UART4_TXD and UART4_RXD
signals. Since the signals are at non-standard pins, I built a special serial adapter cable to bring
TXD via pin 7, and RXD via pin 8.
With this setup, I can transmit serial data from the eval board, but cannot receive. I used an oscilloscope
to determine that receive data goes as far as the RS232 level shifter, but does not come out. The output
is stuck at logic 0.
I have set all registers below using u-boot min. The things I have done so far:
1. Enabled UART4, by writing 2 to 0x48181584. (CL_ALWON registers).
2. Set MUXMODE PINCNTL72 (0x4814091C) to 0xE0002. Connects CPU pin AE6 to UART4_RXD.
3. Set MUXMODE PINCNTL73 (0x48140920) to 0xE0002. Connects CPU pin AF5 to UART4_TXD.
4. Set MUXMODE PINCNTL168 (0x48140A9C) to 0xE0000. Disconnects UART4_RXD.
(not sure if this is needed, but net UART4_RXD is stuck at logic 0.)
5. Set MUXMODE PINCNTL209 (0x48140B40) to 0x40000. Disconnects UART4_RXD.
(not sure if this is needed, but net UART4_RXD is stuck at logic 0.)
6. Set MUXMODE PINCNTL251 (0x48140BE8) to 0x40000. Disconnects UART4_RXD.
(not sure if this is needed, but net UART4_RXD is stuck at logic 0.)
7. Set UART4 MDR1 to 7, to allow setting data rate.
8. Set DLH, DLL to 0x138. This divides 192 MHz input to set 38400 baud.
9. Set other UART registers for simple I/O, and reset MDR1 to zero.
10. Writes to THR come out on connected PC Tera Term window
11. Keypresses in PC Tera Term window do not change value in RHR. They should.
I've done a lot of 16550 work, so I think I did everything I needed to do. In this simple setup, if it
can transmit, it should be able to receive. Looking over the status register values, it appears that
the UART is just not receiving any data.
For those who really love pain, the exact u-boot commands follow:
# Reset or power-cycle the EVAL board. Type a character to stop auto-boot.
# Set bit 1 of MUXmode for the UART0_CTSN pin to become UART4_RXD
md 4814091C 1
mw 4814091C e0002
# Disable other uses of CTS pin
md 48140A9C 1
mw 48140A9C e0000
md 48140B40 1
mw 48140B40 40000
md 48140BE8 1
mw 48140BE8 40000
# Set bit 1 of MUXmode for the UART0_RTSN pin to become UART4_TXD
md 48140920 1
mw 48140920 e0002
# Enable UART4 device in DM8148 CPU, via CM_ALWON register
mw 48181584 2
# Enable uart4 for output
###### This MDR1 mode select MUST be set to 7 (disable) before changing data rate!!!
mw 481A8020 7
mw 481A800C 83
mw 481A8000 38
mw 481A8004 1
mw 481A800C 3
mw 481A8010 3
mw 481A8008 7
mw 481A8020 0
mw 481A8000 55 # Write out "U". The character comes out on Tera Term
md 481A8000 1 # Read a character sent from connected PC. RHR value does not change.
mw 481A8000 AA # Write out ones-complement. A character comes out on PC.
md 481A8000 1 # Read from RHR again, still nothing.
mw 481A8000 41 # Write out "A". See "A" on Tera Term.
Any ideas of what I missed? Do bits 31-8 of the MUXMODE/PINCNTL registers mean anything? I cannot find
any documentation of these bits, which have different values when reading back various MUXMODE registers.
Why is that so?
