• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 2 answers
  • Subscribers 102 subscribers
  • Views 1558 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.

TMS320C6655: SPI problem

Ganz
Intellectual 770 points
Part Number: TMS320C6655
Other Parts Discussed in Thread: SYSBIOS

Hardware: c6655 custom board

1. If the SPI driver is linked with firmware NOT using Sysbios, it  always works.

2. If the same SPI driver is linked with firmware using Sysbios,

i) Set project Debug option "Auto Run and Launch Options -> Run to symbol" as "c_int00".

ii) Connect the debugger to the target board and load the firmware and run, SPI failed.

iii) Re-load the firmware and run, SPI failed.

iv) Repeat step iii) multiple times, it always failed.

v) Re-load the firmware, add a breakpoint at Main(). run to Main(). Re-load the firmware again, remove the breakpoint and run, this time SPI worked.

Below are the SPI register dump and SPI configuration of working and failing scenario.

SPI working scenario --

SPI register dump before config...
0x20bf0000:  0x00000000, 0x00000000, 0x00000000, 0x00000000
0x20bf0010:  0x01000000, 0x00000000, 0x00000000, 0x00000103
0x20bf0020:  0x00000000, 0x00000000, 0x00000000, 0x00000000
0x20bf0030:  0x01010f03, 0x00000000, 0x00000000, 0x00000000
0x20bf0040:  0x80000000, 0x80000000, 0x00000000, 0x00000003
0x20bf0050:  0x00000000, 0x00000000, 0x00000000, 0x00000000
0x20bf0060:  0x00000000, 0x00000000, 0x00000000, 0x00000000
0x20bf0070:  0x00000000, 0x00000000, 0x00000000, 0x00000000

Config SPI with...
SPI_SPIGCR0 = 0x00000000
SPI_SPIGCR0 = 0x00000001

SPI_SPIGCR1 = 0x00000003
SPI_SPIPC0 = 0x00000e03
SPI_SPIFMT0 = 0x00020308
SPI_SPIFMT1 = 0x00020608
SPI_SPIFMT2 = 0x00020610
SPI_SPIDEF = 0x00000003
SPI_SPIINT0 = 0x00000000
SPI_SPILVL = 0x00000000

SPI register dump after config...
0x20bf0000:  0x00000001, 0x00000003, 0x00000000, 0x00000000
0x20bf0010:  0x01000000, 0x01010e03, 0x00000000, 0x00000303
0x20bf0020:  0x00000000, 0x00000000, 0x00000000, 0x00000000
0x20bf0030:  0x01010f03, 0x00000000, 0x00000000, 0x00000000
0x20bf0040:  0x80000000, 0x80000000, 0x00000000, 0x00000003
0x20bf0050:  0x00020308, 0x00020608, 0x00020610, 0x00000000
0x20bf0060:  0x00000000, 0x00000000, 0x00000000, 0x00000000
0x20bf0070:  0x00000000, 0x00000000, 0x00000000, 0x00000000

SPI Enabling...
SPI_SPIGCR1 = 0x01000003

SPI register dump after SPI enabled...
0x20bf0000:  0x00000001, 0x01000003, 0x00000000, 0x00000000
0x20bf0010:  0x01000200, 0x01010e03, 0x00000000, 0x00000303
0x20bf0020:  0x00000000, 0x00000000, 0x00000000, 0x00000000
0x20bf0030:  0x01010f03, 0x00000000, 0x00000000, 0x00000000
0x20bf0040:  0x80000000, 0x80000000, 0x00000000, 0x00000003
0x20bf0050:  0x00020308, 0x00020608, 0x00020610, 0x00000000
0x20bf0060:  0x00000000, 0x00000000, 0x00000000, 0x00000000
0x20bf0070:  0x00000000, 0x00000000, 0x00000000, 0x00000000

SPI failing scenario --

SPI register dump before config...
0x20bf0000:  0x00000000, 0x00000000, 0x00000000, 0x00000000
0x20bf0010:  0x01000000, 0x00000000, 0x00000000, 0x00000103
0x20bf0020:  0x00000000, 0x00000000, 0x00000000, 0x00000000
0x20bf0030:  0x01010f03, 0x00000000, 0x00000000, 0x00000000
0x20bf0040:  0x80000000, 0x80000000, 0x00000000, 0x00000003
0x20bf0050:  0x00000000, 0x00000000, 0x00000000, 0x00000000
0x20bf0060:  0x00000000, 0x00000000, 0x00000000, 0x00000000
0x20bf0070:  0x00000000, 0x00000000, 0x00000000, 0x00000000

Config SPI with...
SPI_SPIGCR0 = 0x00000000
SPI_SPIGCR0 = 0x00000001

SPI_SPIGCR1 = 0x00000003
SPI_SPIPC0 = 0x00000e03
SPI_SPIFMT0 = 0x00020308
SPI_SPIFMT1 = 0x00020608
SPI_SPIFMT2 = 0x00020610
SPI_SPIDEF = 0x00000003
SPI_SPIINT0 = 0x00000000
SPI_SPILVL = 0x00000000

SPI register dump after config...
0x20bf0000:  0x00000001, 0x00000003, 0x00000000, 0x00000000
0x20bf0010:  0x01000000, 0x00000e03, 0x00000000, 0x00000103
0x20bf0020:  0x00000000, 0x00000000, 0x00000000, 0x00000000
0x20bf0030:  0x01010f03, 0x00000000, 0x00000000, 0x00000000
0x20bf0040:  0x80000000, 0x80000000, 0x00000000, 0x00000003
0x20bf0050:  0x00020308, 0x00020608, 0x00020610, 0x00000000
0x20bf0060:  0x00000000, 0x00000000, 0x00000000, 0x00000000
0x20bf0070:  0x00000000, 0x00000000, 0x00000000, 0x00000000

SPI Enabling...
SPI_SPIGCR1 = 0x01000003

SPI register dump after SPI enabled...
0x20bf0000:  0x00000001, 0x01000003, 0x00000000, 0x00000000
0x20bf0010:  0x01000000, 0x00000e03, 0x00000000, 0x00000103
0x20bf0020:  0x00000000, 0x00000000, 0x00000000, 0x00000000
0x20bf0030:  0x01010f03, 0x00000000, 0x00000000, 0x00000000
0x20bf0040:  0x80000000, 0x80000000, 0x00000000, 0x00000003
0x20bf0050:  0x00020308, 0x00020608, 0x00020610, 0x00000000
0x20bf0060:  0x00000000, 0x00000000, 0x00000000, 0x00000000
0x20bf0070:  0x00000000, 0x00000000, 0x00000000, 0x00000000

Observed that the reserved bits of SPIPC0(0x20bf0014) and reserved register 0x20bf001c are different between the two scenarios. After SPI is enabled with SPI_SPIGCR1 = 0x01000003, TXINTFLG of SPIFLG changed to 1 in the working scenario but remained 0 in the failing scenario. Just wondering if the  undocumented reserved bits world provide extra debug information. 

  • 0
    TI__Guru 65405 points
    The team is notified. They will post their feedback directly here.

    BR
    Tsvetolin Shulev
  • 0
    TI__Guru**** 161600 points
    Hi,

    Just wondering if the undocumented reserved bits world provide extra debug information.

    Most likely not. These bits are probably used during chip design phase for testing. There is no publicly available documentation for them.

    As I understand you are using custom firmware (using sysbios, which RTOS version is this??), which is linked with the SPI driver, right? In that case, looking at:
    v) Re-load the firmware, add a breakpoint at Main(). run to Main(). Re-load the firmware again, remove the breakpoint and run, this time SPI worked.

    this looks like some kind of race condition in your system. I'd suggest to try adding a delay in main() and see what is the result.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    TI__Guru* 81335 points
    v) Re-load the firmware, add a breakpoint at Main(). run to Main(). Re-load the firmware again, remove the breakpoint and run, this time SPI worked.

    At these working scenario, all the registers dump look ok? (compare with SPI driver is linked with firmware without BIOS)

    If yes, as Yordan mentioned, there may be issue with race conditions and this issue has nothing to do with device. You can also check with TI-
    RTOS forum experts for their response.

    Thank you.
  • 0 in reply to Raja
    Intellectual 770 points

    Yordan and Rajasekaran,

    Thanks for the response.

    The RTOS version : SYS/BIOS 6.46.0.23, XDCtools:3.32.1.22

    I tried adding a delay(a few seconds) in main, didn't help.

    Up to the point right before SPI is enabled,  the registers dump look OK in both working(lined with or without sysbios) and not working scenario. Actually they are the same except a few reserved bits. only after SPI is enabled with writing SPI_SPIGCR1 = 0x01000003, TXINTFLG of SPIFLG changed to 1 in the working scenario but remained 0 in the failing scenario.

    I'll also make a post to TI-RTOS forum as Rajasekaran suggested.

    GanZ

  • 0 in reply to Raja
    Intellectual 770 points
    Rajasekaran,

    Just notice that the TI-RTOS forum is closed for new post. So how to check with TI-RTOS forum experts?

    GanZ
  • 0 in reply to Ganz
    TI__Guru* 81335 points
    Apologize for the same, let me check. Thank you for your patience.
  • 0 in reply to Raja
    TI__Mastermind 30830 points

    It's pretty hard to guess what the problem is without knowing something about the "firmware using Sysbios" and the "firmware not using Sysbios".

    Is the SPI driver thread safe? Can multiple threads call the SPI driver APIs safely? Is the firmware that uses Sysbios doing that?

    For thread safety reasons, SYS/BIOS usually wants to manage all the interrupts in an application through its Hwi module. How are the SPI interrupts being initialized in the SPI driver? Are there ISR callbacks into user code? If so, what do these callbacks do? If the callbacks invoke any BIOS APIs and the interrupts are NOT managed by the BIOS Hwi module, this is a formula for disaster.

    Alan

  • 0 in reply to Alan DeMars
    Intellectual 770 points
    Alan,

    "firmware not using Sysbios" is single thread. Though "firmware using Sysbios" is multithread, but this problem happened during startup that task sceduling is NOT enabled yet.

    The SPI driver is thead safe, but it 's irrelent in this case since the problem happened basically in a single thread environment.

    The SPI driver work in poll mode, interruprt is disabled. (see registers dump above, SPI_SPIINT0 = 0x00000000)

    I was hoping some of the SPI status register or maybe other DSP staus register could provide more debug information.

    GanZ
  • 0 in reply to Ganz
    TI__Mastermind 30830 points

    I understand you to mean that the problem is happening in main() prior to the call to BIOS_start(). If this is the case,  then it seems like it must be related to how the system is initialized prior to main().

    By default, Timer 0 is initialized but not started prior to main. I doubt that this is an issue.

    Also, interrupts are globally disabled prior to main() and only enabled when BIOS_start() is called. If code in your main() function enables global interrupts prior to calling BIOS_start(), this could cause serious behavioral problems.

    Unless explicitly configured otherwise in the project's .cfg file, the MAR registers are set to their reset values.

    The L1D, L1P, and L2 cache sizes are configured according to information provided in the platform.

    Can you share the project's .cfg file? This will help me understand what may be happening prior to main() that might make a difference in how the SPI peripheral is behaving.

    Alan

  • 0 in reply to Alan DeMars
    Intellectual 770 points

    Alan,

    Yes, the problem is happening in main() prior to the call to BIOS_start().

    I do not want to make the project's cfg file public but could share it with you in private. Let me know where to sent it.

    GanZ

  • 0 in reply to Alan DeMars
    Intellectual 770 points

    After more investigation, it seems the issue may not related SYSBIOS but the compiler/linker.

    Though the linker cmd file does not specify different load time and run time address for 'const' (.const: load >> DDR3), but for some reason the compiler/linker generate different load time and run time address for 'const,', which cause MARs being initialized incorrectly.

    __TI_cinit_table @ 8c4914b8 records: 22, size/record: 8, table size: 176
     .const.8: load addr=8c34cc20, load size=0013b64b bytes, run addr=8c159980, run size=001b0c01 bytes, compression=rle
     .fardata: load addr=8c48826c, load size=0000617c bytes, run addr=8c30a588, run size=0002450a bytes, compression=rle
     .far:NDK_OBJMEM: load addr=8c48e3e8, load size=00002983 bytes, run addr=0080c1c0, run size=00002c2e bytes, compression=rle
     .neardata: load addr=8c490d6c, load size=000003cc bytes, run addr=8c34b4b8, run size=0000111f bytes, compression=rle
     .rodata: load addr=8c491138, load size=000001c0 bytes, run addr=8c34c5d8, run size=000001d4 bytes, compression=rle
     .const.3: load addr=8c4912f8, load size=00000046 bytes, run addr=8bf0dce0, run size=00000040 bytes, compression=rle
     .const.7: load addr=8c491340, load size=00000046 bytes, run addr=8bf69740, run size=00000040 bytes, compression=rle

    ...

    I'll create a new thread in compiler/tool forum for this issue.

    Thanks a lot for everybody's help.

    GanZ

  • 0 in reply to Ganz
    TI__Guru* 96960 points
    Hi Ganz,

    Thanks fort the update. Can you add a link to the new thread and then we'll close this one out.

    Todd
  • 0 in reply to ToddMullanix
    Intellectual 770 points
    This is the link of the new thread.

    e2e.ti.com/.../707496

    GanZ