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

Original question:

CC2652R7: SysCtrlSystemReset not able to reset the chip and chips get stuck/bricked

CC2652R7: SysCtrlSystemReset doesn't always reset to BIM, resulting in bricked code

Edward Colby
Prodigy 40 points

Part Number: CC2652R7

Hi, I've seen that there have been a number of queries on this issue, but none seem to draw useful conclusions for us. Sorry to be asking again.

We're working with on-chip dual OAD, with code derived from bim_dual_onchip and simple_peripheral_oad_onchip both running on a CC2652R7. Both the BIM and application code have been modified.
SimpleLink 8_32_0_07
Custom hardware based on Launchpad
CCS20

Out tests have been careful to ensure that the BIM is properly programmed and present and that the firmware images are present. We've modified the BIM so that its first action is to turn on an LED to evidence its execution. Usually this works well.

With this setup we sometimes find that a call to SysCtrlSystemReset() or SystemReset() - which is macro'd to the same function, fails to restart the BIM leaving the device in a non-responsive state. From this state a hardware reset restarts the system into a good state through BIM to application code.

I think that others have experienced similar problems. Can anyone report on having fixed this one?

Is there a way to inspect the state of the device by, for example attaching the debugger without forcing a reset?

We don't have an external hardware reset available on our products so this is a big risk and problem for us.

  • 0
    TI__Genius 15554 points

    Hello Edward Colby,

    You can connect the debugger to a running target (without resetting the device), follow the steps in our SDK documentation Connect the debugger to a running target section, on the steps to do so. 

    Debugging — SimpleLinkTm CC13XX/CC26XX SDK BLE5-Stack User's Guide 2.2.11.00 documentation

    Thanks,
    Alex F

  • 0 in reply to Alex Fager
    Prodigy 40 points

    Hi Alex,

    Thanks for picking this up.

    I've been able to follow the SDK docs and extrapolate them to connect to the running target in CCS20 (The docs appear to be based on CCS11.2 or earlier).

    Connecting to the running target is extremely helpful, - it's been something that I've been trying to work out for a some time.

    Unfortunately it only allows me to observe the problem and I've not yet found the cause or a fix.

    Issuing SysCtrlSystemReset() appears to cause a reset, but the SoC does not return into the BIM code. Though this doesn't always happen, I am able to cause it with the physical connection to the XDS110 in place or with the board running free and triggering the reset over Bluetooth, or with a button service routine.

    If I hardware reset everything recovers correctly.

    Connecting the debugger to the dead target pauses the target and allows me to inspect the state.
    PC is stopped at 0x1000118e every time. This appears to be a BX instruction.
    AON_PMCTL.RESETCTL.RESET_SRC indicates 6 - Software reset as expected.

    If I hit continue in the debugger the target proceeds to run, executing the BIM code and continuing to the application as expected.

    I've checked the hardware and both LF and HF clocks are behaving as I would expect.

    Is there anything to be learned from the PC always being at this address?
    Alternatively can you suggest a workaround?


    We have several products in production for which this issue could explain warranty issues for us. We're about to launch a new product at significant volume and I'm not able to release the design until I understand this issue.

  • 0 in reply to Edward Colby
    Prodigy 40 points

    Sorry, a bit more detail from digging backwards through the ROM code:

    The point at which we seem to be stalled is

    0x1000118e          BX    LR, with LR containing 0x100011d1

    from which I infer that the ARM is about to switch to thumb code at 0x100011d0. Single stepping this is exactly what happens next.

    Just prior to this instruction is:

    0x1000118c       WFI       this is a Wait for interrupt NOP, which would explain why the system is stopping. What is not clear is what the interrupt is that the ROM code is waiting for. If we had a map of the ROM code we might be able to work this out.

  • 0
    Prodigy 40 points

    At the moment this is starting to look like the HIB bug issue. My mistake for not reading up on this sufficiently before getting this far. Problem appears to correlate with the debugger having been connected.

  • 0 in reply to Edward Colby
    TI__Genius 15554 points

    Hello Edward Colby,

    Thank you for your update, just for my confirmation but when you run the device outside of debugging mode the issue does not present itself?

    Thanks,
    Alex F

  • 0 in reply to Alex Fager
    Prodigy 40 points

    Hi Alex,

    We're working to confirm this, but so far it appears that we don't have the problem as long as we perform an external hardware reset between any debugger connection and the call to SysCtrlSystemReset(). This does seem to match the documented HIB issue.

    We are concerned that we may be seeing just this behaviour with product in the field. The product has a wirelessly charged battery and can get into a state where battery charging from near empty results in a cold boot. Occasionally this seems to lead to completely unresponsive product. This has a low occurrence rate so it is difficult to confirm the cause of the behaviour.

    Is there a case to provide a pull-up/pulldown on the TCLK line to ensure that the line is fully under control during boot?, or are there other recommended ways of preventing the HIB behaviour on production code? - disabling JTAG, test logic reset etc?

  • 0 in reply to Edward Colby
    TI__Genius 15554 points

    Hello Edward Colby,

    One thing that we could try to check is if there could be anything preventing the device from preforming its reset through SysCtrlSystemReset();. If the device's radio/power/clock or some peripheral is holding the power domain awake and has not been shut down properly it could prevent our system reset and "hold it" in a constant need to reset state. 

    One thing I would recommend here is to let the device run normally until the it becomes unresponsive and then use your XDS110 debugger to connect to running target and then check the status of the radio and any other peripherals you use; we are mainly trying to see if anything is actively preventing the reset function. 

    Do you happen to have a watchdog too?

    Edward Colby said:
    Is there a case to provide a pull-up/pulldown on the TCLK line to ensure that the line is fully under control during boot?, or are there other recommended ways of preventing the HIB behaviour on production code? - disabling JTAG, test logic reset etc?

    If there is possibly a case of a HW issue we may need to create another thread to investigate this so we can assign a HW engineer to help. 

    Thanks,
    Alex F

  • 0 in reply to Alex Fager
    Prodigy 40 points

    Hello Alex, Thank you.

    I'm going to mark this as resolved, the behaviour thus far is consistent with the HIB bug issue as linked in a reply above. We're investigating whether pulling the pin with an external pull-up resistor makes the system more robust to restarts in the field.

    Ed