• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 628 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.

UART Boot sends no sequence on serial port.

John Anderson
Genius 5240 points


If I understand correctly I should see some sequence of bytes from the serial port when the DM365 is reset or powered up.  I switched both BTSEL3 and BTSEL2 (pos 1 and pos 2) on.  The manual for the EVM mangles the labeling and logic of these switched beyong belief!!!  But the sfh_DM36x.exe program hangs waiting for the DM365.

I also see nothing on the serial port if I use CuteCom.  Just for confirmation this is what my switch 4 looks like.  I haven't changed anything else.  I'm assuming it's 115200/8/N/1 no flow control.

          B

          T

          S

          E

          L

          3

SW4 - UP UP DOWN DOWN DOWN DOWN

  • 0
    TI__Genius 9490 points

    John,

    Here are some details:

    BTSEL[2:0] = 011 = UART Boot  (datasheet section 3.2.1)

    UART Boot SW4-pin setting [1-2-3-4-5-6] = off-on-on-off-off-off 

    '115200/8/N/1 no flow control' is correct.

    FYI; silicon revision 1.1, the UART Boot is sort of broken, silicon rev 1.2 is fixed. (see errata)

    Let me know if this resolves your issues.

    regards,

    miguel

     

     

  • 0 in reply to Miguel A. Alanis
    Genius 5240 points

    Miguel,

    Correction in my switch illustration.  BTSEL3 should be BTSEL2.

    According to the EVMDM365 tech reference manual the switch setting is....

    UART Boot SW4-pin setting [1-2-3-4-5-6] = on-on-off-off-off-off  (1.5 Boot / Configuration Switch Settings)

    Since pos 1 (leftmost) is designated BTSEL2, this conflicts with the data sheet as you noted....

    BTSEL[2:0] = 011 = UART Boot  (datasheet section 3.2.1)

    So I tried both and got no results either way.  My board is "REV C" and the marking on the chip is....

    TMX320

    DM365AZCE

    YFA-8CA2FEW

    EL

    Could this be a revision 1.1 chip?

  • 0 in reply to John Anderson
    Genius 5240 points

    New information now.  I thought it wasn't working with the BTSEL you suggested from the data sheet but apparently it was.

    The sfh_DM36x.exe application was just "waiting for DM365', but when I went back and checked with CuteCom I was seeing a sequence come out on the serial port.

    What has me wondering is that sfh_DM36x.exe says that it's using /dev/ttyS0, but while it's waiting I can go to CuteCom and open the same device and get a sequence.  If sfh_DM36x.exe had acually opened /dev/ttyS0 I would think that CuteCom would have failed to open it.

    My code sequence is.

    P, 0xf4, t, I, G, 0x09, 0xf8

    Well at least I know the board is doing something.

    John

  • 0 in reply to John Anderson
    Genius 5240 points

    This doesn't look good.  sft_DM36x.exe is seeing the port.  I used the verbose option and it started dumping the erroneous sequence that's being sent.  After reviewing the source code for sfh_DM36x.exe it appears the code sequence should be...

    B, O, O, T, M, E

    and not....

    P, 0xf4, t, I, G, 0x09, 0xf8

    The serial port works fine when running normally.  Could this be the revision 1.1 problem?  Can it be fixed?

    John

  • 0 in reply to John Anderson
    TI__Genius 9490 points

    John,

    DM365AZCE indicates that is Revision 1.1 (as noted in the errata device symbolization)

    Unfortunately this cannot be fixed as it is a Rom bootloader problem, it is fully  fixed in 1.2.

    There is a workaround noted in the errata, not sure how to implement it though..

    fixed the msg..

    Excerpt from errata:

    details of issue are:

    The OSM_SEL (Over-Sampling Mode Select) bit in the UART0 MDR (Mode Definition

    Register) should be set to 0. The current boot ROM code sets it to 1.

    OSM_SEL = 0: 16x over sampling => Divisor value = clk/(16*baud_rate)

    OSM_SEL = 1: 13x over sampling=> Divisor value = clk/(13*baud_rate)

    The choice of divisor value for UART is affected by OSM_SEL for a particular baud_rate.

    workaround:

    To workaround this issue, use higher baud rate code. The desired baud rate of 115200

    should be increased to 16/13 times (i.e., ~141800).

    regards,

    miguel

     

  • 0 in reply to Miguel A. Alanis
    Genius 5240 points

    I think we are just going to order a later revision chip and have the existing one replaced at this time.

  • 0 in reply to John Anderson
    TI__Genius 9490 points

    John,

    Sounds good, sorry for the inconvenience.

    regards,

    miguel