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.

LAUNCHXL-CC26X2R1: After doing software reset, my End-Solution(our PCB not reference board of CC2652) seems hanging.

Part Number: LAUNCHXL-CC26X2R1

Hi TI team,

I tried to do software reset on the reference board of CC2652 without XDS110. The software reset function worked well on the reference board of CC2652.

Then, I tried to use the same firmware on my End-Solution without XDS110. But after I did software reset, my End-Solution(our PCB not reference boards) seems hanging. It means when I pressed any button after software reset, these buttons did not give any feedback.

I need to power cycle my End-Solution to solve this issue but I cannot use this way to solve this issue.  I think something wrong in our PCB(hardware) because the reference board of CC2652 did not have this issue.

Could you help us to check it? If you want any hardware designs to check this issue, please kindly inform us. 

Thanks

  • Hi Lawrence,

    Related E2E post: e2e.ti.com/.../729614

    In what ways did your design deviate from the LAUNCHXL-CC26X2R1? How are you programming the custom board? So a software reset never works, even after a power cycle? We will have to review the hardware design through private messaging if you are unable to publicly share on the forum.

    Regards,
    Ryan
  • I would recommend starting with a much simple example than the entire Zigbee stack, start with the PacketTX and PacketRX examples. They transmit a packet and blink and LED. If they work, then I am not sure the HW is at fault.

    Regards,
    /TA

  • Hi Ryan,

    Last time, we discussed if I removed the XDS110 connection, the software reset should be work.

    I tested software reset and it worked on reference board of CC2652 without XDS110 but our PCB(our boards) could not work. Even, I removed the XDS110 connection.

    We just used the XDS110 on the LaunchPad of CC2652 to flash or burn the firmware into our PCB via JTAG and CCS.

    After I pressed button on my PCB to do software reset and my PCB seems hanging. I need to manually do power cycle for my PCB to fix hanging issue and the software reset could work. It means power cycle make software reset work on our PCB.

    But I cannot always do power cycle manually after I pressed button to do software reset.

    By the way, I already sent a friend request to you on E2E by following YK's suggestion. Could you add me and I will send some hardware design and pictures to you?

    I also found even I just pressed a hardware reset button on our PCB, our PCB hanged as well and I need to do power cycle to fix it. The reference board of CC2652 worked well for hardware reset.

    Thanks

  • You can send Ryan a friend request and then you cand share HW design in private messsage with him for discussions.
  • Hi YK,
    Thanks
  • Hi Ryan,
    Could you add me to be your friends on E2E and I can share some hardware designs to you?
    Thanks
  • Do you send Ryan a friend request?
  • Hi YK,
    Yes.
    Thanks
  • Hi Ryan,
    Do you see my friend request on E2E?
    Thanks
  • Hi Ryan,
    Do you see any friend request from me? I want to add you as my friend to share some hardware information to you.
    Thanks
  • Hi Lawrence,

    As TA has mentioned, can you reproduce this issue with a simpler example?
    From the CC26x2 SDK, please try the gpioInterrupt example. In one of the interrupt handlers (located in gpiointerrupt.c), make a call to SysCtrlSystemReset (this function is defined in C:\ti\simplelink_cc26x2_sdk_2_20_00_36\source\ti\devices\cc13x2_cc26x2_v1\driverlib).

    Once you have verified that you can reproduce this issue on the simpler example, it will be more likely that this is a HW issue and we can forward to the HW team for further investigation.
    I have sent you an E2E friend request, so you can send me the HW design files.



    Regards,
    Toby

  • Hi Lawrence,

    I apologize for the delay in response as I was on vacation from 10/3 until today. I have accepted your friend request. I've already explained that you will have to perform a power cycle after flashing with the XDS110, even if this programmer does not physically exist on the same PCB. The hardware reset button will require further investigation through the design files.

    Regards,
    Ryan
  • Hi Toby and Ryan,
    I tired to use the simple example code of pininterrupt and make a call to SysCtrlSystemReset on our PCB2(the chip of CC2652 + MSP430-2512).
    It could work. Our PCB2 would not hang in the example code of pinterrupt. And I also tried to do hardware reset on this example for our PCB2. It also could work.

    I have to describe more detail about my PCBs.
    I have two type PCBs. One(PCB1) is only used the chip of CC2652. Another(PCB2) is used the chip of CC2652 + MSP430-2512(touch capacitive).
    I found if I run the example code of zed_switch in PCB1 and do hardware and software reset. The hardware reset and software reset could work.
    If I used the same example code of zed_switch in PCB2 and do hardware and software reset. Both reset could not work. My PCB2 would hang.

    Do you help me to check it? I am not sure whether hardware of PCB2 cause this issue because the simple example code of pininterrupt can work for PCB2? Do you still need the hardware designs of PCB2 for this issue, please let me know?
    Thanks
  • You should definitely be investigating any differences between these two boards along with the LaunchPad reference, especially concerning the JTAG, RESET, EGP, and VDD pins. The friend request has been accepted if you need to send the hardware designs through a private message.

    Regards,
    Ryan
  • Hi Ryan,
    I sent the schematic of our PCB via private message to you. Could you help me to check it?
    Thanks
  • I received your PM and we will continue this conversation externally.

    Regards,
    Ryan

  • Hi Ryan and Toby,
    We found after we removed the chip of MSP430-2512(touch capacitive) on our PCB2, the PCB2( the chip of CC2652 + MSP430-2512) could do hardware and software resetting . But we have no idea why the chip of MSP430-2512 will cause this issue. Could you help us to check it?

    Thanks

  • Hi Lawrence,

    What you've stated about removing the MSP430 working, along with the previous statement that the pininterrupt TI Drivers example works, got me thinking about the backdoor bootloader pin. It is enabled by default and active when driven low on pin DIO13 as determined by SET_CCFG_BL_CONFIG Predefined Symbols. It is perhaps no coincidence that this is also the BTN_CTL_1 pin controlled by P1.1 of the MSP430. Can you please change SET_CCFG_BL_CONFIG_BL_PIN_NUMBER to an unused DIO, toggle SET_CCFG_BL_CONFIG_BL_LEVEL, or disable the bootloader by setting SET_CCFG_BL_CONFIG_BL_ENABLE/SET_CCFG_BL_CONFIG_BOOTLOADER_ENABLE to a value other than 0xC5 to see if this makes any difference? SWRA466 for further reference: www.ti.com/.../swra466a.pdf

    Regards,
    Ryan
  • Hi Ryan,
    We tried to change only the value of SET_CCFG_BL_CONFIG_BL_PIN_NUMBER to an unused DIO and our PCB2 could work for hardware and software resetting.
    I want to double confirm whether there are any side effects in TI's RTOS or zigbee for changing the value of SET_CCFG_BL_CONFIG_BL_PIN_NUMBER to an unused DIO?? If there are no any side effects, we will use this way to fix this issue.
    Thanks
  • Hi Lawrence,

    There are no side effects, this is simply the pin used to access the backdoor bootloader if logically low on startup which appeared to be the case when driven by the MSP430. A different pin (or none at all) is used in different stack examples with no adverse behavior. I'm glad this change was able to resolve your issue.

    Regards,
    Ryan
  • Hi Ryan,

    Well noted.

    Thanks