Hi All,
We are trying to implement V.35 protocol in our ISDN Gateway product, the purpose is to make a ISDN video call over the V.35 interface . We are using P1021 processor, initially we tried to use existing UCC_UART driver (in synchronous mode) and GPIO lines as control leads(cts, rts) instead of hardware flow control. Control signals handshake is happening properly and call is getting connected to the other end point, but we are facing issues in data path, while debugging it, we found that V.35 protocol doesn't use start and stop bits in the data stream. But our UART driver is working based on start and stop bits mechanism. Hence we could not proceed further with UART driver to solve the data integrity issues.
After reading the QE datasheet, we understand that we can accomplish data path by configuring UCC in fast protocol, with transparent mode using NMSI.
We have basically following doubts in this approach
1) Is it possible to implement V.35 protocol using UCC in fast protocol, transparent mode with NMSI ?
2) Will clock(tx/rx) and data(tx/rx) signals compatible issues arise, if we change UCC from UART mode to transparent NMSI mode ?
2) Is there any sample driver to access data in transparent mode with NMSI configuration ?
3) Can we control the RTS, CTS signals manually in this NMSI configuration?
1. Transparent mode can be used to send/receive RAW data only, all other protocol-specific features should be implemented in user software.
2. This depends on timing specifications of your remote device.
For software example request please enter a case of NXP online technical support.
3. Yes, you can control RTS, CTS signals of your remote device by software, using GPIO lines.
Have a great day,
Alexander
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi Alexander,
Thanks for your reply.
We need some more information on this
1) in NMSI mode do we need to take care of any other blocks, in case of TDM
we are using SI-RAM and TSA.
2) is there any chance to get data alignment issues (bit shifts) ?, if
happens is there any method to overcome it, I mean using control signals
like cdp, cts, etc
3) in your email you mentioned that
For software example request please enter a case of NXP online technical
support.
could you provide the link to online technical support
On Thu, Jan 7, 2016 at 12:26 PM, alexander.yakovlev <
1. No, for NMSI mode you do not need to use TDM and SIRAM
2. Probably yes, however this depends on protocol specification of the protocol you are using on remote device.
3. Please use the following instruction to enter a case for NXP techhical support:
1) Please open www.nxp.com
2) On the top level menu, select Support > Sales and Support (http://www.nxp.com/support/sales-and-support:SUPPORTHOME).
3) On the bottom of the page, select Hardware & Software.
4) Register with your business email to access the technical NXP online support.
5) A verification email will be sent to your account. Click the embedded link to verify your access.
6) On the NXP online support page, select Contact Support from the top menu and click “submit a new case” to start the process.
Hi Alexander,
We are able to get the data in* external loopback mode*.
Here control pins (RTS, CTS, CD) are configured as GPIOs and RTS is tied to
CD and CTS is grounded permanently.
We have done the following changes for control signals as per QE data
sheet.
.tsa = 0,
.cdp = 0,
.cds = 0,
.ctsp = 0,
.ctss = 1,
.txsy = 1, /*should be cleared in all protocols except
transparent mode*/
.rsyn = 1, /*should be cleared in all protocols (and internal
loopback mode) except transparent operations */
*Sometimes we are able to get the data properly and but sometimes we are
noticing bit shifting *
Working case output
ucc_v35_read
0 1 2 3
4 5 6 7
8 9 a b
c d e f
10 11 12 13
14 15 16 17
18 19 1a 1b
1c 1d 1e 1f
20 21 22 23
24 25 26 27
28 29 2a 2b
2c 2d 2e 2f
30 31 32 33
34 35 36 37
38 39 3a 3b
3c 3d 3e 3f
40 41 42 43
44 45 46 47
48 49 4a 4b
4c 4d 4e 4f
50 51 52 53
54 55 56 57
58 59 5a 5b
5c 5d 5e 5f
60 61 62 63
64 65 66 67
68 69 6a 6b
6c 6d 6e 6f
70 71 72 73
74 75 76 77
78 79 7a 7b
7c 7d 7e 7f
uv35_stop
Non-working case
ucc_v35_read
1 2 4 6
8 a c e
10 12 14 16
18 1a 1c 1e
20 22 24 26
28 2a 2c 2e
30 32 34 36
38 3a 3c 3e
40 42 44 46
48 4a 4c 4e
50 52 54 56
58 5a 5c 5e
60 62 64 66
68 6a 6c 6e
70 72 74 76
78 7a 7c 7e
80 82 84 86
88 8a 8c 8e
90 92 94 96
98 9a 9c 9e
a0 a2 a4 a6
a8 aa ac ae
b0 b2 b4 b6
b8 ba bc be
c0 c2 c4 c6
c8 ca cc ce
d0 d2 d4 d6
d8 da dc de
e0 e2 e4 e6
e8 ea ec ee
f0 f2 f4 f6
f8 fa fc fe
uv35_stop
PS: we tried internal loopback its not working, could you please let us
know is there any way we can avoid bit shifting?
(any clock edge selection settings are there like reading on falling edge
sending raising edge of the clock.)
On Fri, Jan 8, 2016 at 8:16 PM, Vinodkumar Amanaganti <
Hi Alexander,
Thanks for your support.
We have modified existing TDM driver and it's test driver to NMSI mode. Now
we are trying perform loopback in NMSI. But we are not getting any data and
the driver is hanging on read call (as it is waiting on read event queue).
We are not able to find much info on NMSI in QE data sheet, can you provide
any link to understand it a bit more in detail.
We are suspecting pinmux, Here we configured ucc-7 for transparent protocol
with NMSI mode support.
Pinmux for ucc-7 is given below
pio_v35_port2: ucc_pin@04 {
pio-map = <
/* port pin dir open_drain assignment has_irq */
0x0 0x16 0x2 0x0 0x0 0x0 /* SER7_CD_B,
pa-22*/
0x0 0x12 0x2 0x0 0x0 0x0 /*
SER7_CTS_Bi,pa-18*/
0x0 0x13 0x1 0x0 0x0 0x0 /*
SER7_RTS_B,pa-19*/
0x0 0x14 0x2 0x0 0x2 0x0 /* SER7_RXD0,pa-20
*/
0x0 0x15 0x1 0x0 0x2 0x0 /* SER7_TXD0,
pa-21*/
0x1 0x3 0x1 0x0 0x1 0x0 /* SER7_TXCE pb-3 */
0x1 0x1f 0x2 0x0 0x1 0x0 /* SER7_TXC pb-31 */
0x1 0xa 0x2 0x0 0x2 0x0 /* SER7_RXC pb-10 */
/* control pins for V35_2 */
0x0 0x8 0x1 0x0 0x0 0x0 /* V35_2_DTR, pa8
out */
0x0 0x9 0x2 0x0 0x0 0x0 /* V35_2_DSR, pa9
in */
0x0 0xa 0x2 0x0 0x0 0x0 /* V35_2_RI, pa10
in */
/* RS-366-2 pin config*/
0x1 0x1a 0x2 0x0 0x0 0x0 /* V35_2_DSC, pb26
*/
0x0 0xf 0x2 0x0 0x0 0x0 /* V35_2_DLO, pa15
*/
0x0 0xb 0x2 0x0 0x0 0x0 /* V35_2_ACR, pa11
*/
0x1 0x13 0x2 0x0 0x0 0x0 /* V35_2_PND, pb19
*/
0x1 0x17 0x1 0x0 0x0 0x0 /* V35_2_DPR, pb23
*/
0x1 0x1e 0x1 0x0 0x0 0x0 /* V35_2_CRQ, pb30
*/
0x1 0x16 0x1 0x0 0x0 0x0 /* V35_2_NB-1,
pb22 */
0x1 0x15 0x1 0x0 0x0 0x0 /* V35_2_NB-2,
pb21 */
0x1 0x12 0x1 0x0 0x0 0x0 /* V35_2_NB-4,
pb18 */
0x1 0x1d 0x1 0x0 0x0 0x0>; /* V35_2_NB-8,
pb29 */
};
Here PA20, PA21 are configured as SER7_RXD[0], SER7_TXD[0] respectively and
clk16 is used for both TX and RX sections as common clock.
*Can we use SER7_RXD[0], and SER7_TXD[0] as data lines for NMSI, OR do we
need any special pin-config for NMSI mode data lines?*
following control signals as set like this
cdp = 1,
cds = 1,
ctsp = 1,
ctss = 1,
revd = 0,
Could you please help us in setting these and any extra control signals (if
needed in NMSI) values for getting data?
On Fri, Jan 8, 2016 at 11:55 AM, alexander.yakovlev <