• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 3 answers
  • Subscribers 52 subscribers
  • Views 816 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.

CC2650MODA: SRDY / MDRY Pin Directions?

stomp
Genius 4735 points

Part Number: CC2650MODA
Other Parts Discussed in Thread: AM3359, CC2650

Hi,

Trying to get a new project going with CC2650MODA connected to a AM3359.

I have flashed my CC2650MODA device using SmartRF FlashProgrammer2 with the image "simple_np_cc2650bp_uart_xpm_sbl_2_02_01_18a_merge.hex" as provided in the SimpleLink SDK BLE Plugin 1.40.00.42. As detailed here: http://dev.ti.com/tirex/explore/node?node=ANwG0sre.t-m9xHhYyJ5cw__kmPly-e__LATEST

I have made an assumption here that the above programming file is for the CC2650 Booster Pack Board, which could be mounted on top of a MSP_EXP432P401R board as per the examples in the SDK BLE Plugin directory, and I have also assumed that I do not need to program any other files, settings or custom firmware onto the CC2650MODA in order to use the SNP functions.

I have the source for SAP 1.40.00.42 running on my AM3359.

I have traced the wiring from the CC2650 Booster Pack to the MSP4320P401R board and I have found:

TXD => CC2650 DIO0 -> BP Pin J1:3 -> MSP430 P3.2

RXD => CC2650 DIO1 -> BP Pin J1:4 -> MSP430 P3.3

MRDY => CC2650 DIO7 -> BP Pin J1:2 -> MSP430 P6.0

SRDY => CC2650 DIO8 -> BP Pin J2:21 -> MSP430 P2.5

NRESET => CC2650 NRESET -> BP Pin J4:35 -> MSP430 P6.7

I now refer to Project Zero in simplelink_sdk_ble_plugin_1_40_00_42\examples\rtos\MSP_EXP432P401R\bluetooth\project_zero and I find:

1. MRDY P6.0 is configured as as INPUT

2. SDRY P2.5 is configured as an OUTPUT

My understanding was that the M = Master and the S = SLAVE  per the NPI information, and that CC2650MODA would be the slave. 

In which case MRDY would be an OUTPUT from the host MCU and SRDY would be an input.

Further confusion exists files like project_zero.c (example line 617) where the following call is made (Why write to an output?)

GPIO_write(Board_MRDY, Board_LED_ON);

My question is:

When I flash the CC2650MODA with "simple_np_cc2650bp_uart_xpm_sbl_2_02_01_18a_merge.hex", what is the pin directions of the SRDY and MRDY pins on the CC2650MODA, and bonus points if you can point me to a document or otherwise so as I can confirm their direction and IOID numbers.

Thanks

Stomp!

 

  • 0
    TI__Guru 57865 points
    Hi Stomp,
    I'm assigning this to an expert to clarify.
  • 0
    TI__Guru 56590 points

    Hello Stomp,

    Since you are using the module and not the CC2650 booster pack, cant you refer to the example project directly?

    C:\ti\simplelink\ble_sdk_2_02_02_25\examples\cc2650lp\simple_np

    Then you can simply refer to the Board_MRDY and Board_SRDY defines to verify which IOD they correspond to or change them.

    On the SNP MRDY is input and SRDY is output.

  • 0 in reply to Eirik V
    Genius 4735 points

    Hi Eirik,

    Thanks for getting back to me.

    When I program a CC2650MODA with "simple_np_cc2650bp_uart_xpm_sbl_2_02_01_18a_merge.hex"  is the MRDY pin an INPUT into the CC2650MODA or an OUTPUT from the CC2650MODA?

    Some basic testing shows that MDRY is an INPUT into the CC2650MODA from my host and SDRY is an output, but the project zero: simplelink_sdk_ble_plugin_1_40_00_42\examples\rtos\MSP_EXP432P401R\bluetooth\project_zero shows the opposite, MDRY is an INPUT into the MSP430.

    The confusion exists because when I program the "simple_np_cc2650bp_uart_xpm_sbl_2_02_01_18a_merge.hex" onto the CC2650MODA it looks like the device is toggling the SRDY pin and further does not look like its responding to the NPI interface, instead just sending a serial packet.

    I wonder if programming the "simple_np_cc2650bp_uart_xpm_sbl_2_02_01_18a_merge.hex" is all I need for the CC2650MODA, or if I need to program some additional libraries onto the device so as I can run the project zero example on another MCU.

    Thanks

  • 0 in reply to stomp
    TI__Guru 56590 points

    Hello stomp,

    Maybe its the sbl (serial bootloader) that is engaged:

    https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/683707

    Maybe you can try simple_np_cc2650bp_uart_xpm_xsbl_2_02_01_18a_merge instead?

  • 0 in reply to Eirik V
    Genius 4735 points

    Hi,

    I've programmed exactly the file you've mentioned:

    And I've logged the pins:

    You can see my SAP resets the CC2650MOD and then the CC2650 holds its SRDY pin low then brings it high again when its done.  Some time later it transmits.!!!!!

    However, from the link:

    http://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_2_40_00_32/docs/blestack/ble_user_guide/html/ble-stack-common/npi-index.html

    We have this image:

    And you can see that the SDRY pin does not go low again before it attempts to transmit. My SAP does not get an interrupt and has no need to receive the serial traffic.

    I have the same behaviour on two totally different PCB's.

    What can I do? 

    Thanks. 

  • 0 in reply to stomp
    TI__Guru 56590 points

    Hello Stomp,

    I took a sneak peek at the simple_np project from ble_sdk_2_02_02_25. In the SNP_taskFxn initializxation the SNP transmit power-up indication (Asynchronous Command) to SAP. 

      // Send power-up indication to SAP
  SNP_sendPowerUpInd();

    BTW:

    In the _xpm_ versions of the merge hex, flow control is disabled.

  • 0 in reply to Eirik V
    Genius 4735 points

    Hi Eirik,

    Thanks for the explanations.

    I guess here is our thing.... I was hoping for an out-of-the-box experience with the SNP as we've implemented SAP 1.40.00.42 in FreeRTOS on our AM3359. The entire idea of this system is to allow us to use the CC2650MODA connected to another TI MCU, we've had boards built and were looking at heading to customer samples soon.

    We can't possibly use TI-RTOS here for our products, we don't have the tooling or people, and we absolutely have to achieve very high code coverage and testing for product liability reasons. We have to pull apart any vendor code, make it testable, test it and fix any issues we find.

    In the SAP 1.40.00.42 we've noticed that because of the sheer speed of the AM3359 there is timing issues between us releasing nReset and the CC2650MODA releasing its SRDY pin causing a condition where the driver things the CC2650MODA is requesting a transmission.

    So I thought I would abandon SAP 1.40.00.42 and move to SAP 3.01.00.01.... And of course its now changed to be more heavily reliant on TI-RTOS and XDC tools. We don't have any FreeRTOS DPL (Driver Porting Layer) to support non Posix parts of the npi_util.c that use TI-RTOS specifics like Queue_Handle, etc.

    So I'll close this thread, and we'll just have to work something else out...

    Thanks.