• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 31 subscribers
  • Views 1122 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.

TMS570LC4357 - SCI Tx in multiprocessor mode - stop bit tx mistake

Fabio Tartaglione
Prodigy 50 points

Other Parts Discussed in Thread: TMS570LC4357

Hello,

 

i'm working with Hercules LaunchPad TMS570LC43x Development Kit (TMS570LC4357 MCU).

If communication port SCI3 is configured to operate for multiprocessor communication mode

1 start bit - 8 data bit - address/data bit - stop bit (address/data bit used between data bit 7 and stop bit)

the SCI unit mistake the stop bit transmission.

 

If 1 stop bit mode is selected: the stop bit after address/data bit is not sent and the Tx hw line hold the status of address/data bit until next byte transmission.

If 2 stop bit mode is selected: only 1 stop bit is sent after address/data bit and the system work in mode: 1 stop bit.

 

Thanks in advance for any support to this problem.

 

Fabio Tartaglione

  • 0
    TI__Guru 69070 points
    Probably need to see a picture of this to understand.
    Also do you have PARITY enabled?
  • 0 in reply to Anthony F. Seely
    Prodigy 50 points

    Hello Anthony,

    I will provide oscilloscope images as soon as possible.

    No parity bit enabled.

    SCI3 unit work:

    - a) ok if address bit mode (multiprocessor mode) is disabled.

    - b) omits the stop bit if stop bit # is set to '1'

    - c) place 1 stop bit if stop bit # is set to '2'.

    in b) and c) cases the Tx hardware line hold indefinitely the address bit level.

    The problem appears to be related with the proper queuing stop bit(s) after

    the address bit.

    Fabio Tartaglione

  • 0 in reply to Fabio Tartaglione
    TI__Guru 69070 points

    Fabio Tartaglione said:

    in b) and c) cases the Tx hardware line hold indefinitely the address bit level.

    The problem appears to be related with the proper queuing stop bit(s) after

    the address bit.


    Ok ..

    -- do you see it hold indefinitely at '0' ?  or always '1'?

    -- do you also mean that the bus is held indefinitely meaning no further transmit or receive.  or just that the lines are held in this state until the next transmission is initiated?


    -- are there any error flags being set in the SCIFLR register?

  • 0 in reply to Anthony F. Seely
    Prodigy 50 points
    Hello Anthony,

    If SCI3 is in multiprocessor mode and is set #1 stop bit:

    d) If the address bit is set to 0 (data byte) the tx signal is held in state 0 until next tx is initiated
    e) If the address bit is set to 1 (address byte) the tx signal is held in state 1 until next tx is initiated

    in d) and e) cases the track on oscilloscope highlight the absence of the stop bit.

    This is the event sequence:

    After SCI intialization (1st tx):
    1. Tx hw signal is in high state, then after 1 byte tx:
    2. scope trace start bit (tx signal go low for 1 bit period)
    3. scope trace the 8 data bit
    4. scope trace the address bit (0 or 1)
    5. then tx hw signal held in address bit state until next tx is initiated..

    If SCI3 is in multiprocessor mode and is set #2 stop bit:

    The transmission seem be to be ok but only 1 stop bit is sent.

    This is the event sequence:

    After SCI intialization (1st tx):
    1. Tx hw signal is in high state, then after 1 byte tx:
    2. scope trace start bit (tx signal go low for 1 bit period)
    3. scope trace the 8 data bit
    4. scope trace the address bit (0 or 1)
    4. scope trace the stop (tx hw signal state = 1)
    5. then tx hw signal held in high state until next tx is initiated.. (all right but only 1 stop bit is sent)

    Thanks for your support

    Fabio Tartaglione
  • 0 in reply to Fabio Tartaglione
    TI__Guru 69070 points

    Hi Fabio,

    Fabio Tartaglione said:
    4. scope trace the stop (tx hw signal state = 1)
    5. then tx hw signal held in high state until next tx is initiated.. (all right but only 1 stop bit is sent)

    So let's see:


    7 data    Address   Stop    Idle time

     xxxxxxx      0/1            1          1111...

    7 data    Address   Stop    Idle time

     xxxxxxx      0/1            11        111...

    How can you tell exactly that the difference by only looking at the line - when the pattern is exactly the same.

    The only real  way to tell this would be if you ever get a subsequent START from the same processor (not a different processor in case they are sharing the bus)  and if that START were too close to the end of the last frame to not allow time for the second stop bit.

  • 0 in reply to Anthony F. Seely
    TI__Guru 69070 points
    Ok my mistake - I see you said that in the first case you are seeing this:

    7 data Address Stop Idle time

    xxxxxxx 1 1 1111...
    xxxxxxx 0 1 0000...

    If that is the case it would be a silicon bug & we'll need to investigate.
  • 0 in reply to Anthony F. Seely
    Prodigy 50 points
    Hi Anthony,

    i confirm what you wrote in Your post @ May 23, 2016 8:08 PM.

    I'm using 8 data bit (your post refer a 7 bit data content)
    but the behavior is the same for 7 or 8 data bit.

    I am available for any further information or material.

    Thank's for Your support.

    Fabio Tartaglione
  • 0 in reply to Fabio Tartaglione
    TI__Guru 69070 points

    Hi Fabio,

    I tried to reproduce the issue but coming up with a negative result.

    Maybe you can look at the attached program in your environment,  and see if I missed something.

    If not maybe there is some difference in your device config that is causing the problem.

    I made a simple program that sends an address followed by 2 data words.

    I don't see the line being held low after the data words - it returns high in idle..

    The data words are the ones that would have the address bit = 0.


    7484.test_sci3_idle.zip

    Thanks and Best Regards,

    Anthony

  • 0 in reply to Anthony F. Seely
    Prodigy 50 points
    Hi Anthony,

    problem seem to be solved.

    I'm using Hal.Co.Gen 04.05.02 and this tool not allow
    to set the GCR1 register SCI communication mode bit.

    For this reason i had added the following instructions
    in the HL_sci.c file, USER CODE (3) segment:

    ...
    /** - Finaly start SCI3 */
    sciREG3->GCR1 |= 0x80U;

    /* USER CODE BEGIN (3) */
    sciREG3->GCR1 = (uint32_t)(sciREG3->GCR1 | 0x00000001U); // Communication mode: Address-bit
    sciREG3->GCR1 = (uint32_t)(sciREG3->GCR1 | 0x00000100U); // Sleep On
    /* USER CODE END */

    }

    It is my error, the code in segment (3) is executed
    after the SCI3 start (sciREG3->GCR1 |= 0x80U) and the
    result is a wrong behaviour as previously described.

    I change the code in the segment:

    /* USER CODE BEGIN (3) */
    sciREG3->GCR1 &= 0xFFFFFF7FU;
    sciREG3->GCR1 = (uint32_t)(sciREG3->GCR1 | 0x00000001U); // Communication mode: Address-bit
    sciREG3->GCR1 = (uint32_t)(sciREG3->GCR1 | 0x00000100U); // Sleep On
    sciREG3->GCR1 |= 0x80U;
    /* USER CODE END */

    and all seem to works fine.

    The Technical Reference specify that GCR1 configuration register
    can be modified only if SwRST is = 0 (SCI in reset state)
    and i have not read it !!! mea culpa !!! :)

    Thanks for Your support

    Have a nice day.
  • 0 in reply to Fabio Tartaglione
    TI__Guru 69070 points
    super - well thank you for reporting anyway - sometimes there could be a real issue we missed and better to find out sooner than later

    Thanks and Best Regards,
    Anthony