• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 953 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

RTOS/IWR1443: Transferring more than 16 bytes of data as SPI slave

Kevin Lannen
Intellectual 260 points
Part Number: IWR1443

Tool/software: TI-RTOS

Hi, 

I am trying to implement a SPI slave to read the object data out of the MMWave demo on the IWR1443BOOST to control it from an MSP430.

I am able to start the radar unit but when I try to read more than 16 bytes of data (set with the define on line 18). I get a Data Abort exception as shown.

Does the SPI driver not support sending more than 16 bytes at a time? If it does, what is missing from my configuration that is causing this to occur.

All of the memcpy and the buffer sizes are based off the SPI_DATA_OBJ_SIZE define so it should not be running out of space anywhere.

The overhead of having to task switch and call the SPI_transfer function repeatedly will not be able to give me the data rates I need to talk to multiple IWR1443s on a single SPI bus.

I have also seen an Invalid_operation exception show up once instead of the Data Abort exception.

Thanks, 

Kevin

  • 0
    TI__Mastermind 21295 points
    Hi Kevin,

    Please see the mmWave SDK SPI driver unit-tests in the C:\ti\mmwave_sdk_01_02_00_05\packages\ti\drivers\spi\test directory for examples of SPI slave mode throughput testing using the SPI driver.

    Please mark as answered if your question is resolved or reply if more support is needed.

    Regards,
    John
  • 0 in reply to JohnH
    Intellectual 260 points

    Hi John,

    Thanks for the pointer to the examples.

    I have gotten past the exception being thrown. It was due to the the receive buffer being too small.

    However, I am now running into other issues when increasing the length beyond 16. The transaction.status is returning with SPI_TRANSFER_INVAL. I have tried to step into the transfer function to see when this is being set but the lines that are being stopped on do not line up with the code that is actually executing in the mibspi_dma.c file. This is shown in the attached screenshot where the first line that is halted is a comment line.

    Is there a way to load the correct debug information for this so I can determine what line is sending it to the exit?

    Thanks,

    Kevin

  • 0 in reply to Kevin Lannen
    TI__Mastermind 21295 points
    Hi Kevin,

    The SPI library comes pre-compiled in the mmWave SDK. The high optimization level (-O3) used during the compilation may cause strange results when stepping through the code.

    There are instructions for how to re-build the library in the mmWave SDK user guide. The build scripts (makefiles) use the compilation options from the common file at C:\ti\mmwave_sdk_01_02_00_05\packages\ti\common\mmwave_sdk.mak. If you search that file for "-O3" (dash followed by letter O followed by number 3) you will find one place where it is used for the (ARM) R4F_CFLAGS. If you remove that option and then perform a clean compile of the SPI driver then it should re-compile it with no optimization. If you then re-build your project which uses the SPI driver then you should be able to step through the code successfully.

    Regards,
    John
  • 0 in reply to JohnH
    Intellectual 260 points

    Hi John,

    I have removed the -O3 flag from that file and successfully rebuilt the SPI driver. I can tell that the optimizations have been removed since the size of the libspi_xwr14xx.aer4f file went from 186 kB to 216 kB.

    However, when I go to step through the code, the first line that it stops on inside the mibspi_dma.c file is line 2181 which is a commented line 6 lines above the MIBSPI_transfer function. Continuing to step breaks on very few lines that actually contain code, and what is changing in the registers is not consistent with what those code lines do.

    Here are the line numbers that are stopped on:

    2181

    2189

    2193

    2198

    2185

    2198

    2410 (this line is inside a block that is #ifdefed out)

    2413

    2415

    2417

    2418

    (function returns here)

    What else am I missing to be able to step through this code?

    Thanks,

    Kevin

  • 0 in reply to Kevin Lannen
    TI__Mastermind 21295 points

    Hi Kevin,

    Which mmWave SDK version are you using?  When I look at C:\ti\mmwave_sdk_01_02_00_05\packages\ti\drivers\spi\src\mibspi_dma.c I see the following which shows the MIBSPI_transfer() function with its opening brace starting on line 2181 (which would appear to match what you see when debugging).

    Regards,

    John

  • 0 in reply to JohnH
    Intellectual 260 points

    mibspi_dma.cHi John,

    I am using the same one as you. My file in C:\ti\mmwave_sdk_01_02_00_05\packages\ti\drivers\spi\src is attached.

  • 0 in reply to Kevin Lannen
    Intellectual 260 points
    It seems weird that the debugger would not have these line numbers correct since it should be rebuilding from this source file when I changed the optimizations.

    Thanks,

    Kevin
  • 0 in reply to Kevin Lannen
    TI__Mastermind 21295 points

    Kevin,

    Is it possible you have a different version of that file somewhere that CCS is using during debug?  When you hover the mouse over the filename do you see the correct path as shown in the following picture?

    Regards,

    John

  • 0 in reply to JohnH
    Intellectual 260 points

    Hi John,

    This is what I am seeing on the first step into that file.

  • 0 in reply to Kevin Lannen
    TI__Mastermind 21295 points
    Hi Kevin,

    I think I found the cause of the behavior you are seeing with the line numbers being different between the display in CCS and the line number that the debugger says the processor is on. The following thread explains it.

    e2e.ti.com/.../701754

    Windows files normally use CR-LF line breaks (carriage return character + line feed character) to separate one line from the next. There seem to be six carriage-return characters (0x0D in binary, "\r" in regex) without the matching linefeed character (0x0A in binary, "\n" in regex) in the mibspi_dma.c file. These six "incomplete" line breaks are being ignored by the compiler but are being used by the editor in CCS (which is based on Eclipse) thus causing the offset between the line numbers.

    I think the easiest/fastest way to resolve the issue would be as follows.

    1. In CCS with the mibspi_dma.c file open in the editor, execute the following menu option:
    File->Convert Line Delimiters To->Windows
    2. Re-build the SPI library
    3. Re-build the application which uses the library

    Afterward, the compiler and CCS editor behavior should be consistent.

    Please mark as answered if the issue is resolved or reply if more support is needed.

    Regards,
    John
  • 0 in reply to JohnH
    Intellectual 260 points

    Hi John,

    That fixed it for me and I am now able to debug. With the correct debugging I was able to determine that the transaction.slaveIndex was not properly initialized to 0 when I was trying to transmit more than 16 bytes. I have no idea why it was not being set correctly to the default but by explicitly setting it to 0 I can now send up to 64 bytes at a time.

    Thanks,

    Kevin