Bricked Keyfob

If it was from a software issue then Try using SmartFR Programmer.  Also hitting the reset button on the CCDebugger really fast sometimes works.

If it was from exceeding the max voltage on an input, well...

It was a software issue - I burned an image from another device in error in IAR.  But when I try to use Smart RF Flash Programmer to Read the chip it says "Chip is locked! (Erase chip to unlock it)", and if I try to Erase it, it says "Flash erase failed"

If you have the battery in it, then disconnect it from the CCDebugger, remove the battery and then reconnect it to CCDebugger and try again.

Tried that too, but no joy.  Is there a reset process for this device?

The SmarRF does the reset.  On the SmartRF, can you read the IEEE number?

You can also change the speed from fast to slow that may work.  Can you send a screen shot of the SmartRF?

SmartRF can not read the IEEE number.  And I already tried changing the speed with no effect.  I suppose I could send you a screenshot of SmartRF but I suspect you already know quite well what it looks like.

So should I conclude that there is no low-level reset capability designed into the keyfob and send it to the shitcan?

Don't throw it out just yet.  I do recall there was a posting about restoring calibration tables in the flash.  It will probably closer to a manual process where you are writing without authentication.  

Take a look at the Flash Programmer for the CC2540, it might work.  It is in the files tab on the left.

That version of the Flash Programmer is older than the one that I have.  Is there something special about it that is supposed to work when the current version does not?

Just downloaded it.  That is not the Flash Programmer I was thinking of.  There is one that is the code version that you should be able to configure so that you do not have to check for the IEEE or chip ID before you program it.  There was a Flash Programmer floating around the web that allowed you to program the CC2540 without a CCDebugger.  I was almost certain that TI offered something similar.

Thanks,

Hopefully you didn't throw It out.  There was a recent post by a TI Employee that mentioned hot swapping..  If you connect a working CC2540 to the CCDebugger and use SmartRF Programmer if will register that chip.  Then connect the bricked one without resetting the CCDebugger and you should be able to program it.

This is similar to the solution I mentioned about being able to program the chip without having to look for the IEEE and chip ID.

Thanks,

I tried this trick and it doesn't work. I am told by the SmartRF Flash Programmer it cannot erase the Flash. I then removed the battery, this time I can erase the flash memory, however I cannot overwrite it with one of the .hex files I am receiving the message the flash memory is limited to 16KB and the .hex exceed this size.

Any other suggestion?

Are you able to read the IEEE number this time?

Try the "trick" again on the erased chip.  Use the Dongle then switch to the Keyfob and program it.

Since there is no 16KB CC2540/41 device, the device ID is obvioulsly not correct.

There are details for using another flash programmer, http://www.scribd.com/doc/17173149/CC-Flasher-Open-Source-TIChipcon-SOC-Flash-programmer-User-manual 

You can also try using this program and see if you can rewrite the IEEE address. http://sourceforge.net/projects/ccflasher/

I know there is a CC Flasher program on he net somewhere that has the C# code.  You will have to search for it if it is not the one above.

If I remove the battery, I can erase the flash (at least I am told by the SmartRF flash programmer the operation succeeded). Then, I can read the IEEE number which is all 00 with battery removed. If I try to program, I am told the the flash is 16KB as per my previous post when the battery is removed.

If I insert the battery, I am no longer able to erase the flash, I am then not able to program. I can try to append, but in this case I am told there is a communication error with the CC Debugger (number ID0450). And when the battery is inserted, I cannot read the IEEE number.

I also noticed it is not possible to order the CC2450 keyfob alone, we must buy the complete Mini DK.

I will try later the ccflasher and let you know the outcome.

THX

Okay,

I have tried the cc_flasher program and it doesn't work neither, it ends with an error which isn't saying much. Here is the verbatim:

[INFO] searching for 1st cc_flasher
[INFO] usb_find_busses: 4
[INFO] usb_find_devices: 12
[TRACE] 004/001     1D6B/0003
[TRACE] 003/001     1D6B/0002
[TRACE] 002/016     0451/16A2
[TRACE] 002/011     13FE/1D23
[TRACE] 002/005     046D/C52E
[TRACE] 002/004     046D/0991
[TRACE] 002/003     05E3/0716
[TRACE] 002/002     8087/0024
[TRACE] 002/001     1D6B/0002
[TRACE] 001/004     0CF3/3005
[TRACE] 001/002     8087/0024
[TRACE] 001/001     1D6B/0002
[ERROR] Not found

And here is my output from the lsusb -v command (I ran cc_flasher from Linux):

Bus 002 Device 016: ID 0451:16a2 Texas Instruments, Inc.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        32
  idVendor           0x0451 Texas Instruments, Inc.
  idProduct          0x16a2
  bcdDevice            4.50
  iManufacturer           1 Texas Instruments
  iProduct                2 CC Debugger
  iSerial                 3 00110450
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              4 CEBAL
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               5
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               5
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               5
Device Status:     0x0000
  (Bus Powered)

The above output looks like it is for the CC Debugger and not the chip.

This is the program I was talking about CC.Flash.  I'm not sure it is the same as the one you down loaded.  I vaguely remember something about manually configuring the chip, but the species and where I saw it completely eludes me.

You can try working with this http://akb77.com/g/rf/program-cc-debugger-cc2511-with-arduino/ if it doesn't help, well it looks like you will have to shelve it for now.

You can purchase the SensorTag which has a lot of features, but the port pins are not available.  Or you can get the individual EM modules.

One last thing, have you tried putting in a fresh battery?  Unless you have jumpered the resistor, I don't think the CC Debugger is powering the keyfob.

Thanks,

Hum, after looking at the documentation and the code. CC.Flash is a C# utility which implement the CC Programming protocol via Arduino board. Not what we are looking for.

On the other hand, the cc_flasher is using the USB interface to communicate with the target CC2430 over debug interface. The problem being the CC Debugger is no longer the CC2430 CC Debugger and the Vendor ID and Product ID are no longer valid and maybe other specifications as well. So, I found in fact my CC Debugger was found if I change the Vendor ID and Product ID seeking for.  The Vendor ID should be 0x0451 and the Product ID is 0x16a2 and you can see in my previous post in the TRACE info this Vendor ID and Product ID was scanned without being identified as the CC Debugger.

The cc_flasher seems unmaintained since 2007. I will try to contact the author to see if he is willing to update the code and make it working with the recent CC Debugger and chips.

If you are proficient at C# then I think you could modify the code yourself.  If you look at it, the original author almost wrote the code so that you don't need a MCU.  It is very generic and quite impressive when you really look at the work that was done.

I had to wait almost 4 months for my kit to arrive and had rewritten the code to work with the CC2531, but never tested it out properly and don't know where to find it.

Well at least you will gain some experience on the debugging side!

Good Luck,

CC.flash is written in C#, which not the utility I am talking about. cc_flasher is written in C++ and is targetted at the CC243x kit.