• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 20 subscribers
  • Views 281 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.

CC2541: Resetting

Tim Harvey84
Prodigy 180 points
Part Number: CC2541


Tool/software:

We designed a receiver board using the CC2541. Works fine.

In another application we don't want the 2.4GHz radio. We are just using the board, the CC2541 and the I/O.

It generally seems to work fine, without any of the external radio parts installed. We have been using it for a few years with many happy customers.

However, lately we are getting some to reset as far as we know spontaneously when we let them run for several hours or overnight. Some units work flawlessly, while others reset often. It seems like a tolerance or batch issue, and we keep coming back to the CC2541s. One batch works fine. Another batch seems to have issues.

If we disable the watchdog, this seems to go away. We have a 32MHz external crystal. Clock speed and tickspeed at 32MHz. OSC32K set at 32KHz RCOSC. Reset time set for 250ms, and we clear the watchdog timer every 128ms. Yet it still trips, we think.

1) Is there any issue with not using the radio part of the CC2541 we need to account for? The radio defaults off I believe. Do we need to add one or more halRfDisableRadio(FORCE);  to make sure the radio is disabled?

2) Is there anything we need to keep in mind when just using UART, one timer for PWM, and the watchdog?

Thanks,

Tim.

  • 0
    TI__Mastermind 42590 points

    Hi,

    Thank you for reaching out. We will take a look at your queries and get back to you as soon as possible.

    Best Regards,

    Jan

  • 0
    TI__Guru**** 219117 points

    Hi Tim,

    Are you able to swap CC2541 devices between a functional and non-functional board to determine whether the issue follows the CC2541 IC or hardware board?  Are you able to measure the 32 MHz external crystal and ensure that it is not failing?  Also, has the hardware design been submitted to SIMPLELINK-2-4GHZ-DESIGN-REVIEWS? 

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 180 points

    Good morning,

    We have changed out CC2541 and gotten boards to work. The units that reset run fine for the most part. They just reset now and then.

    We have the watchdog time set at 250ms and were petting at 128ms. We changed the code to pet at 64ms and we have not seen a reset since.

    Yay ship it!, Yet something must be hanging up for maybe 130ms or so. It would be nice to know what that is.

    As I mentioned before, we are not using the radio section. External parts are not populated. Is there something there that might be causing an interrupt or something that since we are not using it, don't have in the code?

    Is there a way to completely disable the radio parts other than just the halRfDisableRadio(FORCE);

    Should we leave in the receive code and just dump any results? Could unhandled receives cause a hang up and thus a reset?

    As another thought, is it possible that petting the watchdog with a halMcuWdClear(); call sometimes fails? Maybe if interrupted it doesn't actually reset the counter. With 250ms and 128ms, we would only need one to fail to cause a reset.

    void halMcuWdClear(void) {
    WDCTL= (WDCTL & 0x0F) | 0xA0;
    WDCTL= (WDCTL & 0x0F) | 0x50;
    }

    Thanks,

    Tim.

  • 0 in reply to Tim Harvey84
    TI__Genius 13000 points

    Hi,

    Just to align it is the board with that you are not using the RF that is having the reset issue? did you leave this port open or terminate with a 50 ohm resistor? I would try to see if you terminate the N and P ports with a 50 ohm resistor to ground on each and see if this goes away.

    Thanks,

    Riz

  • 0 in reply to Rizwan Murji
    Prodigy 180 points

    Riz,

    Thanks, we can try that. For now, speeding up the petting to 64ms instead of 128ms seems to have done the trick. Still not sure why, but we can try terminating the RF port better.

    Thanks,

    Tim