• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 860 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.

CC2564MODN: Framing Error

JR Simma
Intellectual 660 points
Part Number: CC2564MODN


We are driving a CC2564MODN (running service pack 1.4) with a TivaC micro.  Sometimes we receive a Hardware Error Event from the CC2564B with an error code of 0xB (i.e. UART framing error).  We've scoped our transmit signal going to the module and it looks very clean and almost exactly 115.2Kbps (less than 2%, which UARTs typically are fine with).  If we receive the Hardware Error Event, we force a complete board reset in 250 ms. 

1) Is there any known issue with framing errors on the CC2564B?

2) Does driving the shutdown pin low reset the CC2564B UART?  I ask because our board reset drives shutdown low for 10 milliseconds. 

  • 0
    TI__Mastermind 27080 points
    This query is assigned to an expert. He will get back soon..

    Thanks
  • 0
    TI__Mastermind 29311 points

    Hello JR,

    JR Simma said:

    1) Is there any known issue with framing errors on the CC2564B?

    There are no such known issues regarding framing error in the CC2564B as long as host UART is working within the tolerance range defined in the CC2564B/CC2564MODN datasheet. Please note that the baud rate requirements in the datasheet are -2.5% to +1.5% per byte and -12.5% to +12.5% per bit. If the host UART is drifting away from these tolerance range, you may encounter the UART framing error.

    JR Simma said:

    2) Does driving the shutdown pin low reset the CC2564B UART? I ask because our board reset drives shutdown low for 10 milliseconds. 

    Yes, driving the nSHUTD pin low and then high completely resets the CC2564B including UART. The chip must be reinitialized after that.

    Best regards,

    VIhang

  • 0 in reply to Vihang Parmar
    Intellectual 660 points
    Thank you for letting me know. The issue really seems to correspond to when the init script is downloaded (just tracked that down this morning). When we download the init script, shortly after the CC2564B becomes ready, we rarely see the UART framing error. However, when we download the service pack roughly 1.7 seconds after the CC2564B becomes ready, we see UART framing error almost every power cycle. I can't find any data on min/max timings for downloading the service pack, but I did notice Muruta's module (which uses a CC25xx) says to download the SP "right after" the device is ready. Can you think of any reason why waiting to download the SP would change the operation of the CC2564B?
  • 0 in reply to Vihang Parmar
    Intellectual 660 points
    Vihang: FYI, this is my 2nd post to your question. I wanted to make sure you saw both. On POR of the micro, we do 4 things: reset CC2564B via nSHUTD pin, wait for chip to become ready, send HCI reset command, and then send service pack.

    After more testing today, it seems like the delay between taking the device out of shutdown and sending the service pack isn't critical. Instead the time between sending the reset command and service pack is critical. We can add a delay of 5 seconds between sending the reset command and service pack, and it breaks the CC2564B. We set the delay to 0 and we haven't seen the error condition since.