• State TI Thinks Resolved
  • Locked Locked
  • Replies 20 replies
  • Answers 4 answers
  • Subscribers 31 subscribers
  • Views 2450 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/TMS570LS1224: SCI2 RX Signal not pulled to 0V when receiving data?

P L
Prodigy 130 points

Part Number: TMS570LS1224
Other Parts Discussed in Thread: HALCOGEN, RM46L852

Tool/software: Code Composer Studio

Good day,

we want to interface a TMS570LS1224 with a GPS receiver over UART. Therefore we use a baud rate of 921600 baud.

In order to have an accurate baud rate, we use the SCI2 module (LIN in SCI mode) where we have the possibility to fine tune the baud rate. (The module is configured to act in functional mode (not GIO mode)):

    /* baud rate fine tuning */
    /* bring the module into reset state */
    scilinREG->GCR1 &= ~( 0x80U );

    /* Formula:
     * P = prescaler part
     * M = 4 bit fractional divider part
     * VCLK_freq / ( 16 * ( P + 1 + ( M / 16 ) ) ) */

    scilinREG->BRS  = 0U;

    /* baud rate currently to: ~921600 baud */

    /* baud rate prescaler */
    scilinREG->BRS |= ( 4U <<  0U );

    /* 4-bit fractional divider selection */
    scilinREG->BRS |= ( 7U << 24U );

    /* enable the module again */
    scilinREG->GCR1 |= 0x80U;

This baud rate business is working quite fine so far, but the signals coming from the GPS receiver (RX) are not properly pulled to 0V, so no data is received on the TMS570LS1224 side.

To clarify I captured the signals with this strange behavior:

Yellow: Signals from TMS570LS1224 towards GPS receiver

Green: Signals from GPS receiver towards TMS570LS1224

If I disconnect the RX pin on the TMS570LS1224 side and capture the signals again, they are properly pulled to 0V as depicted below:

Yellow: Signals from TMS570LS1224 towards GPS receiver

Green: Signals from GPS receiver (but not connected to the RX pin on the TMS570LS1224).

... absolutely no clue what could be the issue here!?!??? Any hints / suggested solutions would be very much appreciated.

Thank you and best regards ...

P.

  • 0
    TI__Guru**** 200256 points
    Hello,

    Please check the pinmux settings. The SCI2 signals are multiplexed with N2HET (6, 13) signals. The NHET signals are used by default.
  • 0 in reply to QJ Wang
    Prodigy 130 points

    Hi,

    thank you for the reply. Is that really so?

    We use the scilinREG "SCI2 module (LIN in SCI mode)" in order to be able to fine tune the baud rate. According the launchpad users guide the pins of this module are not muxed. (See Attachment p. 7, p9)

    The Pins HERCULES_LIN1_TXD and HERCULES_LIN1_RXD on J6 or J10 respectively.

    As for my understanding, only the SCI_TX and SCI_RX pins from the SCI1 module are muxed the way you mentioned it? And they are located on J2 or J11 respectively.

    Thanks for a short feedback.

    Best regards

    P.

    1882.spnu613.pdf

  • 0 in reply to P L
    TI__Guru**** 200256 points
    Hi PL,

    You are right. SCI (pin 38, 39) is multiplexed with NHET signal. SCILIN signals (pin 131, 132) are not muxed.
  • 0 in reply to QJ Wang
    TI__Guru**** 200256 points
    Hi PL,

    The SCILIN signals are routed to TM4C MCU as well. The RX signal might be pulled in TM4C code. Can you please try SCITX and SCIRX? SCITX is located at pin 4 of J2, and SCIRX is pin 3 of J2. Bfore using SCITX and SCIRX, please configure the pinmux since SCITX and SCIRX are muxed with N2HET signals.
  • 0 in reply to QJ Wang
    Prodigy 130 points

    Hi QJ,

    thanks for your reply. The good news is that it works on the SCITX and SCIRX ports. I can send a message and get an answer back. The issue is, that it only works for slower baud rates like 115200 and 230400 baud. When I choose the desired baud rate of 921600 baud the deviation of the baud rate, generated from the TMS570LS1224, is too high, the slave device does not give an answer anymore. (Instead of 921600 it uses 1000000 baud because this is the nearest possible value to configure in the SCI BRS register). This is a problem since I must not overstep a timing deadline in my realtime application.

    This is the reason why I switched over to the SCILIN port, where I have the possibility to configure a more fine grained baud rate (Bit 27-24 of the SCILIN BRS register).

    This is very weird, as the SCILIN RX pin is always driven high. Even if I pull it to the ground manually with an external pull-down resistor (1k).

    It has also no effect if I disable/enable pull control in PIO7 and or reconfigure the pull selection register in PIO8.

    That is what I obtained so far.

    Best regards ...

  • 0 in reply to P L
    TI__Guru**** 200256 points
    Hi PL,

    Using SCIRX and SCITX solves your problem.
  • 0 in reply to QJ Wang
    Prodigy 130 points

    Hi QJ,

    no. It doesn't.

    As I wrote:

    P L said:
    ... The issue is, that it only works for slower baud rates like 115200 and 230400 baud. When I choose the desired baud rate of 921600 baud the deviation of the baud rate, generated from the TMS570LS1224, is too high, the slave device does not give an answer anymore. (Instead of 921600 it uses 1000000 baud because this is the nearest possible value to configure in the SCI BRS register). This is a problem since I must not overstep a timing deadline in my realtime application.

    SCILIN-Port BRS:
    (FFF7 E400h + 2Ch), bit 27-24 I can set a 4 bit M value.

    SCI-Port BRS:
    (FFF7 E500h + 2Ch), I have only bit 23-0 to set a prescale value. BUT NO M VALUE like in 0xFFF7E42C.

    ... or is there another possibility to fine tune the baud rate to make the SCITX/SCIRX ports capable to communicate with ~921600 Bd instead of 1000000 Bd?

    Best regards
    P.

  • 0 in reply to P L
    TI__Guru**** 200256 points
    Hello,

    Only SCILIN module has additional 4-bit fractional divider M to refine the baud rate selection. The SCI module (SCI only) uses 24-bit integer prescaler P value to select the required baud rates, it doesn't have divider M.
  • 0 in reply to QJ Wang
    Prodigy 130 points

    Hi QJ,

    yes that is obvious because retrievable from the Technical Reference Manual. Nevertheless it's no solution approach why the RX pin of the SCILIN Port is always driven high.

    See image again:

    Green signal contains the answer from the slave device. But the TMS570LS1224 SCILIN RX drives against aggressively.

    I would use the SCI Port, if I had a better approximation towards 921600 baud than just 1000000 baud. This is a deviation of almost 8 %. Quite a distance.

    Must be a configuration issue? But beyond explanation for me so far. I've tried almost all configuration options of the control registers of the SCILIN port. Is there something else that has to be taken care of? By the way: I took the HALCoGen generated code as a basis where I enabled the LIN driver to operate in SCI mode.

    Thanks and best regards

    P.

  • 0 in reply to P L
    TI__Guru**** 200256 points
    Hi PL,

    When you use the SCILIN signals on Launchpad header, do you connect TX and RX signals to your part directly? or add another component (RS232 level driver)?

    Is the RX signal driven high at low baudrate? I'd like to do a test on my bench to figure out what causes this problem.
  • 0 in reply to QJ Wang
    Prodigy 130 points

    Hi QJ,

    yes I connect the signals directly. On the following image it becomes visible. I captured this with the SCILIN RX pin DISCONNECTED from the TMS570LS1224. Like this the signal coming from the slave device looks OK:

    The signals are in the range of [0V, ..., 3.3V] -> TTL

    Maybe there is a misconfiguration on the TMS570LS1224, that I'm unaware of. An internal RS-232 level driver which is currently activated erroneously? Or do I need to explicitly set the SCILIN port to TTL mode somewhere?

    I will try the lower baud rates on the SCILIN port later on today in order to answer your question. So far, I tried the lower baud rates only on the SCI port.

    Thanks for the hint regarding the RS-232 level driver.

    Until later then ...

    Best regards
    P.

  • 0 in reply to P L
    TI__Guru**** 200256 points
    Thanks PL

    BTW, both Launchpad and your GPS board should have a common ground.

    You can ask a experienced HW technician to modify the board (minor change) to do another test:

    Lift the pin 34 (LINRX) of U7 to detach it from the PCB.

    Please do it carefully, otherwise will damage the board.
  • 0 in reply to QJ Wang
    TI__Guru**** 200256 points

    Hi PL,

    Another way to use 921600 baudrate on SCITX/SCIRX is to lower your CPU frequency.

    1. Lower the PLL output frequency to 148MHz instead of 160MHz (default)

    2. Re-Configure SCI baudrate to 921600, the actual baudrate becomes 925000

  • 0 in reply to QJ Wang
    Prodigy 130 points

    Hi QJ,

    I'm sorry I was pulled to another project these days. But now I was finally able to test your suggestions.

    I changed the PLL multiplier as you suggested. With the baud rate 925000 I am close enough to 921600. I can communicate with the slave device @921600 bd now on the SCI port. Thank you much for this hint.

    What I did not try so far is to lift the pin and test the SCILIN port. I was a bit scared since I could damage the board like this.

    There is a common ground. We power the slave device through the TMS570LS1224 @3.3 V.

    With the changed PLL multiplier I have to test if all the other slave devices work as intended. We also use the timer, I^2C and SPI modules to interact with other slave devices.

    I'll get back to you as soon as I tested all the other slave devices.

    Thank you again and best regards

    P.

  • 0 in reply to P L
    TI__Guru**** 200256 points
    Hi PL,

    Please lift the pin if the new PLL value works for you. Thanks
  • 0 in reply to QJ Wang
    Prodigy 130 points

    Hi QJ,

    why should I?

    With the new PLL value I'm using the SCI port, not the SCILIN port.

    Or is there another coherence?

    Best regards
    P.

  • 0 in reply to P L
    Prodigy 130 points
    Hi QJ,

    ... or in other words, is there a possibility to disable the RM46L852 CPU instead of lifting the pin. We just work with the R4F CPU.

    Best regards
    P.
  • 0 in reply to P L
    TI__Guru**** 200256 points
    Hi PL,

    Do you mean to disable the TM4C129 device? No, this device is used to route JTAG signals to Micro USNB port. Without this device, you will not be able to use USB for JTAG.

    I suggest you to use another SCI with lowered CPU speed.
  • 0 in reply to QJ Wang
    Prodigy 130 points

    Hi QJ,

    thanks for the reply. Yes that's what I meant. Sorry, I wasn't very precise formulating the question.

    That's what I figured, that it has something to do with the USB JTAG.

    Well it seems that I have to use the SCI Port with the lowered CPU frequency.

    All in all this is a workaround and not really a solution. It appears to me like repairing fine mechanics of a typewriter with a sledge hammer.

    Is there an erratum going to be published regarding this issue? After all this makes the SCILIN port unusable if connected through J6 or J10.

    Best regards
    P.

  • 0 in reply to P L
    TI__Guru**** 200256 points
    Hello PL,

    This is not silicon issue. This is related to system design. For SCI RX, there are two signal input sources which interferes each other. We can add a 0ohm resistor or a jumper to SCI TX at TM4C129 SCI RX pin, so user can select the SCI RX input source. Thanks