• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 51 subscribers
  • Views 395 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.

CC2652P7: ROM bootloader does not respond to 0x55

Shuyang Zhong
Expert 5115 points

Part Number: CC2652P7

My customer is using CC2652P7 with a Linux host processor. In a test they found that about a half of their boards failed when flashing through ROM bootloader. The CC2652P7 chip on the board does not respond to the 0x55 hand shake.

The customer has tried to switch the CC2652P7 between a good board and a failed board, the problem goes with the board, not the chip.

I have two questions regarding to the ROM bootloader:

1. Does the ROM bootloader use external 48MHz crystal or internal RCOSC?

2. Is there a way to debug the ROM bootloader, like through JTAG? Or other suggestions to debug why the chip is not responding?

Best regards,

Shuyang

  • 0
    TI__Guru**** 172049 points

    Shuyang,

    Shuyang Zhong said:
    1. Does the ROM bootloader use external 48MHz crystal or internal RCOSC?

    The documentation shows no restrictions regarding the clock source, only that it must be a fraction of 16 in relationship with HPOSC (48MHz for the CC26x2 devices).

    Shuyang Zhong said:
    2. Is there a way to debug the ROM bootloader, like through JTAG? Or other suggestions to debug why the chip is not responding?

    You can inspect the bootloader code by connecting to a blank device using JTAG, as it will be held in the bootloader code.

    Regarding the overarching problem of programming the boards via the bootloader, many variables can be tweaked to try to isolate the root cause. If you haven't done so, can you ask your customer to check the bootloader application note SWRA466 and its companion bootloader demonstration software?

    https://www.ti.com/lit/an/swra466d/swra466d.pdf

    This is a known good utility and procedure that can help debug this.

    Also, another point that can be related is the data rate of the transfer. Did your customer try to reduce the speed of the transfers and see if the success rate improves?

    At last, did your customer check the connections on an oscilloscope or logic analyzer to see if the issues are coming from noise on the lines or other electrical form of data corruption?

    I will think about additional details that might influence this scenario and report back in case I find anything relevant.

    Hope this helps,

    Rafael

  • 0 in reply to desouza
    TI__Expert 5115 points

    Hi Rafael,

    Can you confirm which clock source is used by default in ROM bootloader?

    The customer tried with the baud rate decreased to 9600 and the communication succeeded 100%, so I suspect if the ROM bootloader uses RCOSC_HF and the communication failed before due to the error of the RCOSC.

    There is another finding during test, the customer found that the first attempt after reset will always fail on the boards with the problem, but if a reset is not issued after power-up, there is a chance (about 50%) the communication will succeed. Do you have any idea how the reset can affect the ROM bootloader?

    Best regards,

    Shuyang

  • 0 in reply to Shuyang Zhong
    TI__Guru**** 172049 points

    Shuyang,

    Please apologize for the delay. The UART baudrate and clock source is mentioned in the TRM section 10.2.2.1.1 but it is not restricted to RCOSC or XOSCHF. Basically the enablement of the clock source is done in the FCFG:OSC_CONF.XOSC_OPTION flag (section 11.4.1.59 of the TRM).

    I can't think of any influence the reset would have over the functionality of the bootloader, apart from a possible scenario where the external clock oscillator is not fully stable when the bootloader is used. That and other aspects such as power, noise, etc. I would investigate these avenues first.

    Hope this helps,

    Rafael

  • 0 in reply to desouza
    TI__Expert 5115 points

    Hi Rafael,

    Thanks for the clarification, I have confirmed through the OSC_DIG_map1 -> STAT0 register that the bootloader uses HF RCOSC.

    And the customer has located the root cause of this issue which was not related to the clock, the issue has been fixed by adding a pull-up resistor on UART TX pin, the host internal pull-up was not working properly.

    Thanks for your support and this post can be closed.

    Best regards,

    Shuyang