• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 50 subscribers
  • Views 483 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.

custom application with CC2540

Vasco Tesi
Intellectual 590 points
Other Parts Discussed in Thread: CC2540

First of all, I thank the TI staff for the very useful support they give with this forum.

We are about to implement a custom portable, low energy application using CC2540 (as module to module communication) and some other dedicated hardware.

Following some design considetation about which I'd like to receive some feedback.

We have totally copied schematic and layout of keyfob reference design, just adding some other peripherals.

The peripherals added are : timer 1 used as PWM ( channels 1 and 2 --> P1.1 and P1.0  ) , one digital output (P1.3)  internal op amp (P0.0 IN+ , P0.1 IN- and P0.2 OUT) and 4 ADC inputs (P0.3 through P0.6).

If we correctly understood, the use of these peripherals is completely up to the application, and the board configuration can be updated starting from BLESimplePeripheral or KeyfobDemo and adding some instructions in hal_board_cfg.h.

Is it correct to foresee a CC debugger interface made of the following signals : DC, DD, RESETn ( with associated RC 2.7k  /  1nF ) , GND and VDD (from board to debugger) ?

We initially planned to make some small test programs to test the functionality of the peripherals and attached  devices, before integrating the code with BLE functionality.

In the board configuration instructions of these small programs, can we assume that the I/O configuration for the debug interface will be taken by IAR debugger, or shall we add some instruction for the configuration of relevant pins ? What about disabling the RF core, if we don't want to use it in our initial tests ?




 

 

 

 

 

  • 0
    TI__Genius 10955 points

    Vasco Tesi said:
    Is it correct to foresee a CC debugger interface made of the following signals : DC, DD, RESETn ( with associated RC 2.7k  /  1nF ) , GND and VDD (from board to debugger) ?

    Yes, this looks correct.

    Vasco Tesi said:

    In the board configuration instructions of these small programs, can we assume that the I/O configuration for the debug interface will be taken by IAR debugger, or shall we add some instruction for the configuration of relevant pins ?

    When in debug mode, the configuration for pinsP2.1 and P2.2 will be taken by the on-chip debug interface, and you don't need to worry about the configuration. When not in debug mode, these pins are controlled as other GPIO. As long as you have no other connections to P2.1 and P2.2 than the debugger, you should be fine with the default configuration out of reset, where these pins are inputs with pull-up enabled.

    Vasco Tesi said:
    What about disabling the RF core, if we don't want to use it in our initial tests ?

    The RF core is disabled out of reset. If you want to test your interfaces without using the radio, you can build a stand-alone project where you do not include the BLE library. I am not very familiar with the BLE stack, but I believe that if you want to have the BLE library in, you would still have the radio disabled as long as you don't send any commands to the BLE stack.