• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 52 subscribers
  • Views 538 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.

Original question:

CC2652P: NPI change UART to SPI in Host test

LAUNCHXL-CC1352P: STM32 MCU communicating with Host Test NPI over SPI

Samuel
Prodigy 80 points
Part Number: LAUNCHXL-CC1352P
Other Parts Discussed in Thread: CC1352P

Hello everybody,

I posted my problem under my last question but I think it is better to post it under a new thread. Thanks to Nate for the help on the other question.

Currently I am working to code the master NPI side on my STM32 MCU for the communication with a LAUNCHXL-CC1352P-2 development kit for BLE communication.

I configured the Host Test example to use SPI to communicate with the Network co-processor. Additionally I changed the SPI frame format in Host Test to CPOL=0 and CPHA=0 and the bit rate to 4MHz.


I then tried to send the HCIExt_Reset_SystemCmd (0xFC1D) to the BLE-chip. In the picture below there is the MISO data which my MCU send out to the BLE-chip. 

Debug on Host Test side: 
NPI_handleMrdyEvent(void) gets called, so handshaking is working correctly. Also oscilloscope shows the correct handshake procedure and timings.
Then NPITLSPI_CallBack() gets called. But instead of the shown MOSI data in the picture above, the BLE-chip only received 0xFE followed by 0. See picture below.

I tried other SPI frame formats and random data payloads but nothing seems to change. The CC1352P only receives the first byte (SOF) but not the following 6. 

EDIT:

Here is the picture of the whole communication with SRDY and MRDY handshake.

regards, 

Samuel

  • 0
    TI__Expert 3886 points

    Hi Samuel,

    I've assigned this thread to someone. But in the meantime, given that there is an associated thread, did you try the steps suggested by Nathan in that thread?

    BR,
    Andres

  • 0 in reply to AndresM
    Prodigy 80 points

    Hi Andres,

    I tried the HCIExt_Reset_SystemCmd (0xFC1D) Nathan suggested. In the first picture is the SPI frame with the command displayed. I am currently debugging the application on my MCU and the host-test side. Why the SPI on host-test only receives the first byte of the communication is the main problem. But the debugging will take at least 2 days till i have enough time for that. 

    It would help me a lot if someone could tell me how a valid HCI command should looks like when it is send over NPI with SPI (maybe some logic capture).
    Or if someone could say if my logic capture/frame format is correct. 

    You have some good examples and documentation on how a valid NPI with UART communication looks like (with BTool) but not so much on NPI with SPI.

    regards,
    Samuel

  • 0 in reply to AndresM
    Prodigy 80 points

    Hi Andres,

    I debugged and found out that the SPI_transfer function returns a SPI_TRANSFER_CANCELED status. Which means that SPI_transferCancel must be called, right?

    This function should then cause the problem.

    static void NPITL_MRDYPinHwiFxn(PIN_Handle hPin, PIN_Id pinId)
{
    // The pin driver does not currently support returning whether the int
    // was neg or pos edge so we must use a variable to keep track of state.
    // If the physical state of the pin was used then a very quick toggle of
    // of MRDY could be missed.
    mrdy_state ^= 1;

    if (mrdy_state == 0)
    {
        mrdyPktStamp = txPktCount;
        NPITL_setPM();
        if ( taskMrdyCB )
        {
            taskMrdyCB();
        }
    }
    else
    {
        transportStopTransfer();
    }

    // Check the physical state of the pin to see if it matches the variable
    // state. If not then edge has been missed
    if (mrdy_state != PIN_getInputValue(MRDY_PIN))
    {
        mrdy_state = PIN_getInputValue(MRDY_PIN);

        if (mrdy_state == 0)
        {
            mrdyPktStamp = txPktCount;
            NPITL_setPM();

            if (taskMrdyCB)
            {
                taskMrdyCB();
            }
        }
        else
        {
            transportStopTransfer();
        }
    }
}

    But when i look at the oscilloscope my MCU doesn't make quick toggles on the MRDY pin.

    regards,
    Samuel

  • 0
    Prodigy 80 points

    I have now been able to fix the problem.

    For everyone who wants to know how the SPI frame should look like, see the picture on my comment from Oct 12. 

    What fixed my problem was the reassignment of SPI and MRDY, SRDY pins as well as adding us delay on de-assertion of the MRDY pin on my application MCU side. In the end, the problem was not on TI's side but rather on mine. Sry for the inconvenience.

    regards,
    Samuel