• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 52 subscribers
  • Views 376 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: setting breakpoint drastically reduces transmit power

Stuart Smith
Prodigy 160 points
Other Parts Discussed in Thread: CC2540

We have a curious problem with a CC2540-based product.

We normally read an RSSI of -74dBm at a distance of about 3m in a particular orientation, and there are many FCS errors. The low power is unexpected. While attempting to debug the problem, we set a couple of breakpoints in the CC2540 code. If we briefly stop at these breakpoints, the device functions as expected! - RSSI jumps to -30dB, we have no problems seeing the device or making a connection to it.

The breakpoints were in some code which set the CC2540 transmit power to +4dBm. Since the default is 0dBm anyway, we experimentally commented out the code which sets the transmit power. If we stop at the breakpoints, the RSSI is about -34dBm, and everything works. If we don't stop at the breakpoints, the RSSI is about -77dBm and our product doesn't work.

Another, similar firmware for the same product doesn't exhibit this problem. We've tried delaying in the firmware around where the breakpoints would normally be set, but this does nothing. Does this ring any bells for anyone?

  • 0
    TI__Guru 57865 points

    Hi Stuart,

    I'm not sure what you are doing here. If you debug (and break) during a connection, the connection will be terminated because the devices get out of synch. If you are not connected, you are advertising and will only be able to get RSSI on incoming packets (ex. scan request packets) which might be from any device actively scanning.

    Maybe I'm misunderstanding something here. Could you please clarify what you are doing in a bit more detail.

    Best Regards

    Joakim

  • 0 in reply to J Lindh
    Prodigy 160 points

    Joakim,

    Thank you for your rapid reply.

    There was no connection, we were observing the RSSI of the advertising packets from the TI sniffer application. Sorry I wasn't very clear - I wasn't talking about the RSSI of incoming packets observed by the device, I was talking about the difference in RSSI of the advertising packets received by another device from this device.

    But it is all moot, because we found our problem - our device uses an RF amplifier after the CC2540, which is switched by one of the internal state signals which can be multiplexed onto P1.0..P1.5 using the OBSEL special function. The multiplexer state isn't preserved over PM2 or PM3. We thought we were restoring the state, but we weren't, and now we do - problem solved. We still don't know why the debugger influenced it.

  • 0 in reply to Stuart Smith
    TI__Mastermind 23440 points

    Hi,

    Just to let you know, the stack already has an option for external range extender (2590/91) if you call the command HCI_EXT_ExtendRfRangeCmd().

    It will (non-negotiable) put gain mode on P1.1 (high=rx high gain), P1.2 PA_EN, P1.3 LNA_EN. This is also using OBSSEL, and reconfigures OBSSEL at wakeup. RF_OBS_DAC_PD and RF_OBS_AAF_PD for your information.

    Best regards,
    Aslak