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.

IWR6843AOP: Can I use the IWR6843AOP with a MMWAVEICBOOST Launch Pad SPI connections

Part Number: IWR6843AOP
Other Parts Discussed in Thread: MMWAVEICBOOST

I've updated an example lab (3d people counting) to send data to the SPI bus. The Bus opens fine and and the spi transfer command is called (with no erro), however it never returns and is stuck in an infinite loop  due to  MIBSPI_checkTGComplete status 1 is never returned. I've set the DPI switches on the AOP board as per documentation. I'm at a loss as to what i may have missed. We're using a raspberry pi as our spi master and it all checks outs. 

Any help would go a long way

  • Hi,

    Have you reviewed the SDK documentation on the SPI driver found at C:\ti\mmwave_sdk_03_06_00_00-LTS\packages\ti\drivers\spi\docs\doxygen\html\index.html?

    You could also drag the SPI source into your project to build it yourself in order to debug it to see where it gets hung up. Have you tried this?

    Best,

    Nate

  • I have read the SPI documentation in detail and can't see where i'm going wrong. I've reviewed the test code and noticed some calls to Pinmux function call which i'm investigating now. Unsure what you mean drag the SPI source into my project are you referring to the test or the library ?

  • Debugging with a fine toothcombe i have found where i hang. in the file mibspi_dma.c @ line 2274, 

    semaStatus = SemaphoreP_pend(ptrMibSpiDriver->transferCompleteSem, ptrMibSpiDriver->params.transferTimeout);

    We have checked ptrMibSpiDriver->params.transferTimeout to discover a timeout of 4294967295, I am left with 2 question How do i change the timeout and how is the semaphore triggered. Either of these question will help me understand what is going wrong. 

  • Hi Duncan,

    It appears to me that this semaphor should be posted on line 1692 of the same file. I would recommend against changing the timeout time, rather, just setting the SPI transfer to non-blocking would be the preferred way of doing this. Have you taken a logic analyzer to the SPI lines to see if the data is being transferred right? This would help us ensure that data is being transferred.

    Best,

    Nate

  • I have applied the Logic Analyser and no data was seen, also, SPI_Transfer only operates in BLOCKING Mode according to the docs

  • Hi Duncan,

    Do you see any traffic on the PICO line? SPI traffic should begin with data sent from controller to peripheral, so if there is no traffic from the central device first, then I would expect there to be problems with the peripheral communicating.

    Best

    Nate

  • We saw the clock and chip select line behaving as expected, do we have to put data on the PICO line I'm expecting data on the POCI line as that what software is trying to do, do i need to send some data to the radar chip in order to active the data out?

  • Hi Duncan,

    A typical SPI configuration would have the Central Device requesting information from the peripheral device, but I suppose you could simply broadcast right from the peripheral to the central unprompted. When you pend on the ptrMibSpiDriver->transferCompleteSem, the semaphor there should have a value of 1. When I see it being initialized in MISPPI_open() though, it seems to be initialized with a value of zero (line 1959 of mibspi_dma.c).

    ptrMibSpiDriver->transferCompleteSem = SemaphoreP_create(0U, &semParams);
    Could you step through to make sure it gets initialized as your expect in the SPI_open() call, then verify that the value has changed from 0 to 1 when you get to the SPI_write() call? If so, then we'll be able to find the location where the value changes, and understand better why it's happening.
    Best,
    Nate

  • I have followed the code through and i see the the semaphore created, however the value of 1/0 is a little confusion as its a void* and all i see in the debugger is a memory location. In order to dereference and inspect the contents of the struct i would need to what type to cast it to.

  • Hi Duncan,

    I believe a uint8_t would be fine to cast it to, you could also just look directly in the memory in the memory tab.

    Best,

    Nate

  • cheers Nate, done this and we're see a 0 once we create the semaphore

    is this likely to be the cause if so what controls this semaphore creation

  • it does not get set to 1 in the spi_write function we sit there with a 0

  • Additionally, I think your switch settings are off. Looking at the schematics for the IWR6843AOPEVM and the MMWAVEICBOOST, it looks like S1.6 needs to be off and S1.9 needs to be on in order to access the 40 pin header on the backside of the EVM.

    Best,

    Nate

  • Thankyou so so much