• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 40 subscribers
  • Views 562 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.

CC3235MODASF: Not receiving ack from custom board connected through FTDI FT4232H

Khalid Rajab
Intellectual 262 points
Part Number: CC3235MODASF
Other Parts Discussed in Thread: EMBEDDED-PROGRAMMING, UNIFLASH

Hello all,

I am having difficulty connecting to a CC3235MODASF on a custom board.

The CC3235 is connected via UART through a UART bridge (FTDI FT4232H-56Q). The pins are connected as follows:

  • CC3235 UART0 Tx (pin 46) <-> FTDI Channel A Rx (pin 13)
  • CC3235 UART0 Rx (47) <-> FTDI Channel A Tx (pin 12)
  • CC3235 nRESET (35) <-> FTDI Channel A RTS (pin 14)

I have been following the procedure in SWPA231 (using the pyFTDI API), and have also tried the Embedded-Programming tool (which gets stuck at wait for ack), and Uniflash.

The SOP settings are: [210] = [010] (although I have tried other variations).

The following is an example output:

A couple of things I'm not sure of:

  1. Break signal. The instructions state, "Send a break signal (sending continuous spacing values, no start or stop bits)". I have tried various spacing values (0x20 in figure above, all 0s, etc.), but could you confirm what I should be sending?
  2. Is the SOP1 behaviour correct, i.e. it pulls up only when In reset, or should it be permanently pulled high? 
  3. Note that I get (0x04, 0x00, 0xFF, 0xE2, 0x00) which follows the General Message Format, but I can't find an op code E2. I don't receive the expected ack (with opcode CC).
  4. Finally, after reset and flushing UART lines, I have tried sending the Get Storage List command, without response.

Received command (0x04, 0x00, 0xFF, 0xE2, 0x00) with break signal:

Get Storage List:

I have tried to include only relevant info, but please let me know if there's anything else which would help.

Otherwise, do you have any suggestions one what I'm doing wrong?

  • 0
    TI__Mastermind 45725 points

    Hey Khalid,

    Could you share the schematic portion of the UART connection? I'm concerned since your pin numbers mentioned don't line up with the data sheet:

  • 0 in reply to Dylan Hubbard
    Intellectual 262 points

    Hi Dylan, 

    Are those the pins for the CC3235MODASF? Because they don't match up with the datasheet I have:

  • 0 in reply to Khalid Rajab
    Intellectual 262 points

    Schematics

    CC3235MODASF

    FTDI FT4232H

  • 0 in reply to Khalid Rajab
    TI__Mastermind 45725 points

    Hey Khalid,

    My apologies, I was looking at the IC pinout and not the module. I looked over your connection again and don't see any issues with it. The SOP1 behavior also looks okay. Let me loop in one of my SW experts to help look into this a little more from the software perspective.

  • 0 in reply to Dylan Hubbard
    TI__Guru 64305 points

    Hi,

    SOP settings are: [210] = [010] is OK but you need to make sure that when releasing the nReset, the SOP1 is detected as '1'. From the logic it is hard to tell if this is the case. Basically, even without sending anything to the device, if the target connection is good, you should get an ACK (0xcc) right after releasing the nReset assuming the SOP lines are OK and the UART RX is on BREAK (de-asserted to '0' continuously).

    Please check that this is the case.

    Regards,

    Shlomi

  • 0 in reply to Shlomi Itzhak
    Intellectual 262 points

    Thanks Shlomi, Dylan,

    I've tried your suggestions, but no luck yet.

    Sending BREAK with SOP1 high after reset.

    I have also fixed SOP1 high:

    In both cases, I don't receive an ack, or anything else from the Tx line.

    The curious thing is, if I send a non-BREAK signal (e.g. 0x20 in my opening post), I receive a response in Tx (but not the CC ack), and nothing after triggering reset (see first post).

    One of the local team is helping me out, so if we find a solution I'll post it here. In the meantime, any other suggestions are welcome.

  • 0 in reply to Khalid Rajab
    TI__Guru 64305 points

    Hi,

    This is strange (could be the the device is broken for some reason).

    What about the other SOP lines? are those in logic '0' during the nReset?

    Shlomi

  • 0 in reply to Shlomi Itzhak
    Intellectual 262 points

    Hi Shlomi,

    Roger Monk helped me sort the issue, and I'm glad to say that the board is working correctly now. I'll record the issues here for the benefit of anyone else who experiences similar.

    There were two main issues, that differed between the custom driver (pyFTDI api) and Uniflash, which is partly what made it more difficult to identify:

    1. pyFTDI api: Rx/Tx blocked after flushing UART. After triggering nReset, when I flush the UART ports a second time I can no longer send/receive. This is the main reason I was missing communications, as before the second flush I would receive communications. Note: I haven't yet identified if this is a pyFTDI issue or due to my driver; if it's the latter (it might be the threading in Python) and I'll update this post.
    2. Uniflash with FTDI FT4232H. The nReset pin is held high through the FTDI chip. As Uniflash isn't controlling the FTDI pins, I have a manual reset button. However, it turns out the nReset was being held in a hard high so the the CC3235 didn't detect the manual reset. Solution was to disconnect the nReset line to the FTDI.

    There were some other minor issues I had with pyFTDI, e.g. the length of time waiting for ack after reset, which meant that sometimes the ack would be missed, but the two issues above were the main problems. Thanks everyone for the help.