CC2540 custom board based on KeyFob - doesn't work after power cycle

Hello Steven,

When you remove the CC Debugger (with battery in place, hopefully a new one!), does the program work?

Yes... the CC Debugger won't flash it unless the battery is in the Fob.  I'm able to flash it, remove the CC Debugger, and have the device work as intended.  However, if I remove the battery and put it back in (power cycling), I'm no longer able to advertise or connect via BLE.

Bump... Does anyone have any ideas on this?  I've tried changing the initial state of the GAP role after startup to Advertising... directly after programming the board and clicking Scan on BTool I can see and connect to the device just fine... however after removing the battery and putting it back in I can no longer see or connect to the device.  Is there a problem with floating pins on a reset?  I have the same 8-pin header as the KeyFob on my board for progamming, but also added another 8-pin header so that I can connect a serial port on the MCU.

I thought there might be a problem with the pins on the header for the UART port so I configured it to not open until a BLE connection has been made.  Still get the same results.

Thanks,

Steve

You should connect the RESET_N with a 2.2K resistor and 1nF cap as in the schematic diagram for the KeyFob and the USB Dongle to see if that makes a difference.

Although the chip has a Power-On Reset, your layout may be bringing the reset pin low enough to cause it to reset.  Possible, but unlikely.

The insertion of the battery may be causing something similar to "contact bounce". Possible, but unlikely though.  You could try using a Schmitt triggered chip as the battery source and pulse it off and on.

From the http://www.ti.com/lit/ds/swrs084c/swrs084c.pdf it states that a 1us Low pulse on the RESET_N will reset the chip, but does not guarantee that all the peripherals are reset.

Thanks for the reply.  I have the cap and resistor in there as suggested by the KeyFob schematic.  I've checked the RESET_N pin and there doesn't appear to be any coupling causing it to go low.

I've also compared the RESET_N pin's output on inserting the battery to that of TI's KeyFob side by side and they look nearly the same - TI's has a longer discharge rate after removing the battery though (whereas mine falls around 20x faster).  I see some "contact bounce" on both boards, but nothing that would cause the chip to reset.

So I'm thinking the RESET_N pin is OK.

Any ideas on what else to check? 

If the clocks are working and your code is running and you've tried resetting the chip while the battery is in and it still doesn't work, then this problem is beyond my experience with this chip.

As a test though, put  a very long delay just after the board is initialized (5 seconds) and before any of the HAL and OSAL functions are called.

If you have the CC Debugger connected with the battery in place, does it work properly after you press the Reset button on the CC Debugger?

Hi Steven,

Strange problem! My guess would be some kind of hardware bug. Could I have a look at your schematic and layout?

/Fredrik

Hi all,

Just wanted to post an update.  I switched out the 128 for a 256 chip, and am now able to successfully install and restart the TI KeyFob firmware.  However, if I add code for a UART port to the project, I get back to the exact same problem as before, where I am able to use the fob successfully directly after programming but not after restarting.  Below are a couple of screenshots I've taken showing any and all differences between TI's keyfobdemo.c and mine.  I've changed the preprocessor definitions to what's below.  Are there ANY differences between the two which would cause these problems?

INT_HEAP_LEN=3000
HALNODEBUG
OSAL_CBTIMER_NUM_TASKS=1
HAL_AES_DMA=FALSE
xPLUS_BROADCASTER
HAL_LCD=FALSE
HAL_LED=TRUE
HAL_UART=TRUE
HAL_UART_DMA=FALSE
HAL_UART_ISR=2
CC2540_MINIDK

Hi Steven,

When you remove the coin cell and put it back in again, how long do you keep it out? Could you please try either of the following:

- Remove C21, and then power cycle by removing and inserting the coin cell

- Remove the coin cell, shorth VDD and GND, reinsert the coin cell

/Fredrik

I know this is from some time ago, but I think I may be having a similar issue on a new design. Did anyone ever get any resolution on this issue? Does slowly dropping the power cause some things to remain in a weird state? Any help would be appreciated.

Thanks,

Mack