• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 853 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.

Issues bringing up a new CC2541 based board

Louis Gerbarg
Prodigy 40 points
Other Parts Discussed in Thread: CC2541, CC2540, CC253

I just finished populating a new board design based on a CC2541. This is a new board rev, and previously we had been using a CC2540. At first glance everything looks correct, and when I plug it into my CC debugger I get a green light and the device is correctly identified. When I try to program it I get errors from the SmartRF tool claiming that my firmware exceeds 16KB flash (I am using the 256K parts). It looks as through all reads from the device are returning full pure zeros, as the device is reporting a MAC address of 00:00:00:00:00:00, and if I dump the config page or anything else that is all I see. These results are consistent whether or not I am powering the device off the CC debugger or a battery.

I modified a version of ccflasher to work with it so I could get a look at the output:

[26.07 16:18:20:04097] main, cc-tool 0.15

[26.07 16:18:20:04097] main, command line: ./src/cc-tool --log cc2541-2.log --reset
[26.07 16:18:20:04512] usb, open device, VID: 0451h, PID: 16A2h
[26.07 16:18:20:04512] usb, set configuration 1
[26.07 16:18:20:04525] usb, claim interface 0
[26.07 16:18:20:04527] usb, get string descriptor 2, data: CC Debugger
[26.07 16:18:20:04527] programmer, request device state
[26.07 16:18:20:04527] usb, control read, request_type: C0h, request: C0h, value: 0000h, index: 0000h, count: 8
[26.07 16:18:20:04527] usb, control read, data: 41 25 CC 05 32 00 01 00
[26.07 16:18:20:04527] device, name: CC Debugger, ID: 2906, version: 05CCh, revision: 0032h
[26.07 16:18:20:04527] programmer, set debug interface speed 0
[26.07 16:18:20:04527] usb, control write, request_type: 40h, request: CFh, value: 0000h, index: 0001h, count: 0
[26.07 16:18:20:04527] programmer, connect target
[26.07 16:18:20:04527] programmer, enter debug mode
[26.07 16:18:20:04527] usb, control write, request_type: 40h, request: C5h, value: 0000h, index: 0000h, count: 0
[26.07 16:18:20:04527] usb, control write, request_type: 40h, request: C8h, value: 0001h, index: 0001h, count: 48
[26.07 16:18:20:04527] usb, control write, data: 43 43 32 35 34 31 20 20 20 20 20 20 20 20 20 20 44 49 44 3A 20 32 39 30 36 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
[26.07 16:18:20:04528] programmer, reset target, debug mode: 1
[26.07 16:18:20:04528] usb, control write, request_type: 40h, request: C9h, value: 0001h, index: 0000h, count: 0
[26.07 16:18:20:04539] programmer, read debug status
[26.07 16:18:20:04539] usb, bulk write, count: 2, data: 1F 34
[26.07 16:18:20:04539] usb, bulk read, count 1: data: 00
[26.07 16:18:20:04539] programmer, debug status, 00h
[26.07 16:18:20:04539] programmer, halt failed

I can see that initially I am getting data over the CC interface (usb, control read, data: 41 25 CC 05 32 00 01 00), but then CPU seems to halt after it switches into debug mode. Any thoughts?

  • 0
    Guru 22270 points

    Check your oscillator or the traces to it.  

    I had the ame problem with the first board I designed.  Everything worked perfectly the first time I connected, to my utter surprise!  It could be programmed and ran everything just fine.  The second day, nothin'.  Got all zeros.  Tried everything.  I found that when I held it in a certain position, at just the right angel, with my fingers in a certain spot and reset the debugger, it would program.  

    That's when I knew I had solder connection problems.  A lot of time was wasted

  • 0 in reply to Greenja
    Guru 31280 points

    Hi,

    In addition to greenja's suggestion, check if the ground pad of cc2541 is well soldered, when it's not,

    the whole thing "misbehaves".

  • 0 in reply to Greenja
    Prodigy 40 points

    It appears the issue was a bad connection between the crystal and the SoC, specifically one of the pins on the SoC didn't get enough paste and was not down. Not that is fixed I am getting errors that device is locked and can't be erased, but I suspect the issue there is that I probably overheated something. I am pretty confident I can get the board up from here though.

  • 0 in reply to Louis Gerbarg
    Guru 22270 points

    Good to hear you are making progress.

    If you have another board and components, my advice would be to start again.  Chalk the first board up as a learning experience and apply what you've learned to the next board.  I had the same problem with the chip running hot after trying to reposition and rework the board.  

    You may have better luck than I did, but there was a lot of time wasted.  In the end I was left with partially working ports and board that looked very bad.

    Best of luck!

  • 0 in reply to Louis Gerbarg
    Guru 31280 points

    Louis Gerbarg said:
    Not that is fixed I am getting errors that device is locked and can't be erased, but I suspect the issue there is that I probably overheated something.

    Oftenly it's a sign of partially connected ground pad of CC253/4x devices.