• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 81 subscribers
  • Views 728 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

LAUNCHXL-F28377S: no SCI after power-up

Ruslan Kadyrov
Prodigy 140 points

Part Number: LAUNCHXL-F28377S

Hi e2e community,

I have an issue similar to described in this post: the program boots from flash after power up, but there is no SCI (UART) connection with cable plugged until reset button is pressed.

I went a little further in troubleshooting and noticed that the problem persists even if the DSP is powered from external +3.3V power supply (with JP1 removed) and not from USB. FTDI chip is still powered from USB.

That post has solutions based on voltage monitoring and additional capacitance to reset circuit which cannot be applied to my case as the board remains powered when the USB cable is unplugged.

Any help is appreciated

  • 0
    TI__Guru 60865 points
    Hi Ruslan,

    Do you not see the virtual COM port on the PC until the reset is pressed, or you just don't get any UART communications via SCI?

    Are you trying to send data or receive data first?

    Which way are the boot mode pins set on the device DIP switch (S1)?
  • 0 in reply to Devin Cottier
    Prodigy 140 points
    Thanks Devin, I should've put these details in the post:
    I see the virtual COM port on my PC and see D8 LED indication when I type in terminal.
    The board is in "Boot From FLASH" mode with debug enabled (S1 all in ON position).

    Your second question reminded me that in my case I'm trying to see the command line prompt (there is a tiny command line interface implemented in DSP) in response to a new line or any other character. Debug session indicates that the reason I don't have it is because I'm stuck in SCI_readCharBlockingFIFO() function. This is a standard function provided as a part of device support package for my LAUNCHXL. I see that under the hood of that function there is a SCI_getRxFIFOStatus() checking that doesn't pass after USB cable is plugged back and characters sent from the terminal. Once DSP is reset, it behaves normally.
    I don't see these functions to be used in design examples, so cannot check if this is an issue with my implementation of command interface.
  • 0 in reply to Ruslan Kadyrov
    TI__Guru 60865 points

    Hi Ruslan,

    If the device is stuck until it is reset, the most likely cause is that it detected a message error. You can see the list of error conditions in the TRM (spruhm8) in the register definition for the "SCIRXST" register.

    Some of these error conditions require the SCI module to be reset for the error condition to clear (resetting the whole device also accomplishes this):

    What you might need to do is modify the SCI software to monitor for these error conditions and then issue a module reset as-needed.

  • 0 in reply to Devin Cottier
    Prodigy 140 points
    Devin, thank you, this resolves the issue.
    It turned out that break-detect and framing-error detect flags go high resulting the RXERROR go high as well. SCIRXST register toggles between 0x02 and 0xB2
    I checked it with the scope, RX line goes low for several ms as the cable unplugged and then goes low again as the cable re-connected.
    It explains the break and framing errors. At this point I'm not going to dig out to the reasons why FTDI chip does it.

    Now I'm checking for the SCI_RXSTATUS_BREAK and do the SCI_performSoftwareReset() if it is high. In current implementation of the firmware the checking takes place in ISR for a timer. In the deployment board I'm planning to bring the USB cable connection status to a GPIO pin, configure interrupt for that GPIO bank, and generate software reset as the cable is connected.

    Thanks again for your help.