• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 1504 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.

CC2540 Flash Programmer

Hugh
Prodigy 40 points
Other Parts Discussed in Thread: CC2540

Hello,

I am creating a custom programmer to utilize the two-wire debug lines on the CC2540 to load an image onto it.  I am having problems with chip response through the debug lines during power-intensive operations such as chip erase or burst writes.  The unit I am programming appears to program fine on the SmartRF programmer, and I have used a network analyzer to capture the bytes being communicated between the two.  Most commands work and illicit responses from the target DUP which I have decoded and applied to the custom programmer.  For example, I have captured:

55 00 | FF 00 //nop

56 E5 92 | FE 00 //move value from @0x92 to accumulator

57 75 92 00 | FF 00 //move byte 0x00 to @0x92

56 E5 83 | FE 00 //move value from @0x83 (DTPR0 high byte) to accumulator

56 E5 82 | FE 00 //move value from @0x82 (DTPR0 low byte) to accumulator

...which I have also replicated.  However, much of these commands are non-essential, and I assume they are used by the SmartRF programmer for some purpose or another.  When it comes to chip erase, however, the expected behaviour is:

0x10 0xFF 0xA2...0x34 0xA2...0x34 0xA2... etc. ...0x34 0x22

...where 0x10 = chip erase command, 0xFF = 8-bit cycle wait on target response, 0xA2 = target response (chip erase busy), 0x34 = status query, 0x22 = target response (erase complete).  However, in my case,

0x10 0xFF 0xFF 0xFF 0xFF...<timeout after x seconds>

...or even if we force a status query, the target is still driving the line so a 0xFF is read.  In our case, x is set to 3, and target voltage is set at 3.5V.  I suspect insufficient power being supplied during the poll, but I can't find any specifications anywhere what the programming voltage and current draw requirements are.

Any input is appreciated, thanks.

  • 0
    TI__Genius 13620 points

    Hugh,

    Have you read this Application Note: AN118 -- Flash Programming of CC253x/4x Devices (www.ti.com/lit/swra410)? It describes in detail how to program the device, and also includes source code showing how it can be done. 

    If you're able to program the device using SmartRF Flash Programmer, I don't think your issue is the power supply. 

  • 0 in reply to M
    Prodigy 40 points

    Let me clarify, the SmartRF programmer is working fine; it is powered separately via its own powered USB port and hub.  However, our custom programmer is also its own system, powered through USB only via its own powered USB port and hub as well; neither share any common power source.

    According to AN118 section 6 Erasing FLASH memory - chip_erase(), the scope diagram indicates 3 8-bit debug clock cycles that generate 3 8-bit debug data messages that are being captured.  The resulting bit stream viewed is a 0x10 from the debugger, a 0xFF generated by the target as a wait cycle, and a 0xA2 being returned to the debugger by the target.  The target drives the DD line low immediately following the second 8-bit clock cycle, signalling a response is ready to be transmitted to the debugger.  This is what I observe from programming using the SmartRF board via a network analyzer (inconsequentially, the chip erase command being issued is a 0x14 instead).

    In our custom implementation, however, we issue a 0x10 (or 0x14), change the debug data pin direction from debugger-->target to target-->debugger, perform an 8-bit debug clock toggle as a wait cycle, and never receive the data ready signal from the target; we continue to read 8-bit wait cycles until the process times out at 3.00s.  The clock toggles at ~1.85us during wait cycles, with a ~7.25us pause between each 8-bit read.  I assume there are no other required 'configuration' or 'setup' messages that need to be issued by the debugger prior to a chip erase, though the SmartRF board appears to query chip versions, IDs, and sets up DMA or something as a default procedure.  Something similar occurs during burst writes.  All other regular messages (ie. DMA configurations, chip IDs and versions, etc.) appear to be unaffected by this problem, and the DUP responds as expected.

  • 0 in reply to Hugh
    TI__Genius 12900 points

    It does not sound to me like this is a power issue, but just to make sure, make sure the signalling levels from your custom debugger is the same as the CC2540 supply voltage.

    • As stated in AN118, the only thing you should need prior to a CHIP_ERASE() command is to reset the target (CC2540) to debug mode.
    • Bit 2 in the CHIP_ERASE() command is don't care, so 0x10 and 0x14 are in fact the same (ref. swra124 page 5, swru191 page 56).
    • The SmartRF Flash Programmer uses the GET_CHIP_ID() command to check whether the device is in debug mode. I would recommend this as a sanity check.

    Have you tried the code example that comes with AN118? Are you able to use it to program your CC2540?

    Br,
    ABO 

  • 0 in reply to TIABO
    Prodigy 40 points

    Our code is very similar to the code example shown in AN118.

    It appears that I was able to properly program the unit once I tightened line toggle timing on our custom programmer.  I noticed anomalies in the data line near when the directions changed, and was able to start getting responses back after some code optimization and waveform shaping.  This confuses me a bit because from the documentation it seems the debug interface is fairly forgiving, and allows the debugger to generate the clock signal as it sees fit.  I have analyzed both the fast and the slow programming modes from the SmartRF board, where the clock periods range from 0.57us to 6.5us, respectively; our clock signal comes in at about 3.5us.  Direction changes occur inline and as quickly as possible; direction is kept input to debugger at all times except when transmitting to target.  We are concerned if timing is too strict that our custom programmers (used in production) may have enough variances across each unit that we cannot guarantee a programmer will perform correctly.

  • 0 in reply to Hugh
    TI__Genius 12900 points

    Hi,

    I'm not sure how much more I can help without seeing the scope images of your debug communication. 

    The timing requiremets for the CC debug interface are listed in the CC2540 datasheet (SWRS084, page 14). Some information is also found in the CC253x/4x user's guide, as mentioned by this E2E thread: http://e2e.ti.com/support/low_power_rf/f/158/p/216749/764412.aspx#764412

    The debug interface should support up to 12 MHz clock (Debug Clock = DC), so you are operating well within this limit.

    As a general tip: In the scenario where the data line (DD) is output (seen from the debugger), minimize the time from the last falling edge on DC to when DD is set as input (seen from debugger) to avoid drive conflict.

    Br,
    ABO 

  • 0 in reply to TIABO
    Prodigy 80 points

    Hugh,

    Were you ever able to definitively resolve this issue?  It's possible I'm running into something similar.

    Thanks,

    Dan

  • 0 in reply to DanB
    Intellectual 255 points

    Hi!

    I have the same problem with 0x10 command.

    Anybody solved it?

    Sergey