• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 30 subscribers
  • Views 765 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/TMS570LS1227: Issue using SCI instead of LIN/SCI2

audry kouanda
Prodigy 220 points
Part Number: TMS570LS1227
Other Parts Discussed in Thread: HALCOGEN,

Tool/software: Code Composer Studio

Hello,

I am using  a TMS570LS1227-PGE µC for an inertial sensor project. One of the feature needed is to use UART communication between the µC and other device (PC).

FIrst, for prototyping, I used the LIN/SCI2 port (calling sciSend on scilinREG), the one who pass through USB link, and everything worked well.

Now that we want to make our own card, I tried to make the communication through the SCI port (sciREG). This is the only thing that changed between the 2 programs loaded: sciREG instead of scilinREG. However, this does not work at all: communication does not work on PC side, and when checking with a scope on the SCIRX/TX pin (pin 38/39), what we see is very weird: it does more look like a clock or something like 010101.. more than an actual frame.

Observations and tests made on our own made board or on the TMS570 Hercule LaunchPad are the same (pin 38/39 of µC are wired to pin J11-333/34 on the launchpad)

I am using FreeRTOS, configured with HalCogen - TMS570ls-1224PGE-FreeRTOS, as I could not find a freeRTOS project for the tms570ls1227...

Any clue of what could the problem be ?

Thank you for your help

Audry

  • 0
    TI__Mastermind 21425 points
    Hello,
    Did you change pin mux? SCI is muxed with NHET and EPWM.

    Best regards,
    Miro
  • 0 in reply to Miro
    Prodigy 220 points

    Hello, thanks for answering.
    So it appeared that we messed up with the scope and didnt look at the right pins -__-
    However, since we fixed this and look at the right pins, here are the problems I face:
    -Code is the same between the launchpad and the home made board.
    - Code use SCI (not LIN/SCI2) to transmit data. This is wired to pins J11-33/J11-34 or J2-3/J2-4 on the launchpad
    On the launchpad, the data sent by the µC and received on the PC are OK
    On the home made board, even if code is the same, data read on the SCI_TX pin is wrong: bytes seems to be inverted (endiannes issue or like)..
    I mean, data are tranmitted to the TX pin, but it is definitively not correct once we get them on the PC using a serial monitor.
    I don't understand since the code/configuration/pinmux is absolutely identical between launchpad and home made board. Only the hardware is different, but can't figure out any hardware problem which could have such consequences as data sent but wrong. (would have exepcted no data sent or so)

    Here is a screenshot with the Launchpad SCI TX signal in blue, and the home made board SCI TX  signal  in grey.

    The code is the same but as you can see, signals are different...

  • 0 in reply to audry kouanda
    TI__Mastermind 21425 points
    Hello,
    Regarding the FreeRTOS porting, please take a look at this document: www.ti.com/.../spna237.pdf

    Best regards,
    Miro
  • 0 in reply to Miro
    Prodigy 220 points

    Hi

    thanks for answering.

    it appeared that the quartz on the homemade board was 20MHz, while it's 16MHz on the launchpad.

    I made the change in halcogen, in the clock tab ( changed the 3 16 values to 20): now it seems to work better but still, not as well as on the launchpad.

    Are there some other settings that I forgot about concerning the different quartz fresuency ? I am fearing implication of such difference...

  • 0 in reply to audry kouanda
    TI__Mastermind 21425 points
    Hello,
    Please, check SCI baudrate settings.

    Best regards,
    Miro
  • 0 in reply to Miro
    Prodigy 220 points
    yes I already did, baudrate is set to 120000, which give actual baudrate 120192
  • 0 in reply to audry kouanda
    TI__Mastermind 21425 points
    Hello,
    Changing oscilator frequency have impact to PLL frequency. If no changes are made to PLL settings after changing oscilator clock this may lead to system and peripheral frequencies that are out of range. For example maximum f_HCLK is 160MHz for PGE package and 180MHZ for ZWT package. Maximum f_vclk clock is 100Mhz. Please, check whether all frequencies are in recommended operating conditions - see table 5.5 in device datasheet.

    Best regards,
    Miro
  • 0 in reply to Miro
    Prodigy 220 points

    Hello,

    Actually, checking the quartz frequency with a scope, I found out that the real frquency was not exactly 20MHz but 20.1.

    Changed made in HalCogen and everything is working fine now !

    I also changed the PLL settings to make sure that I respect the range (under 160MHz), but it worked without this, even if the PLL frequency was arround 220 MHz (which is definitively supposed to be out of range)...

    Anyway, the problem was clearly due to quartz frequency not coherent with µC settings.

    I would appreciate explanation about why was it working even without changes to PLL settings (which were out of range), while changes were made about oscillator setttings, but that's for my own knowledge, system works anyway...

    Thanks for your help.