• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 285 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.

OMAP-L138: DSP affecting ARM 1-wire Bus

A. Kirchhoff
Intellectual 535 points
Other Parts Discussed in Thread: OMAP-L138

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

I appear to have a conflict between the ARM and DSP cores on an OMAP-L138. 

On the ARM side, I am using a Linux device driver that implements a Dallas 1-Wire bus, which we use to communicate with a fuel gauge (Dallas 2780).  The 1-Wire interface uses a single GPIO and is bit-banged, so the driver includes some busy-loops to perform the required timing to about the microsecond level.  This interface works fine when only the ARM is running. 

When the DSP runs and uses the BIOS PSP SPI driver to send bytes on the SPI0 bus, the 1-wire bus begins to have errors and crashes after about 2 minutes.  Using a scope to capture the 1-wire traffic, I noticed that the timing changes and potentially varies when the DSP is running compared to when the ARM runs by itself.

Also, the same problem occurs when using a different GPIO on the ARM, so I don't think it is a conflict with the particular GPIO pin being used.

Any thoughts on what is going on?  Does the DSP BIOS modify the processor's clock settings when it runs?

Thanks,

abkirchhoff

 

  • 0
    TI__Guru 62975 points

    It's possible that concurrent activity from the DSP/SPI may result in competition for resources.  For example, if both cores are using external memory, the data/instruction access times in your wait loop may vary.  I think it would be a good idea to take advantage of a TIMER to implement interrupt- or tick-based delays.

  • 0 in reply to tlee
    Intellectual 535 points

    tlee,

    Thanks for the reply.  It appears that some resource conflict is the problem.  I found a I2C to 1-wire bridge chip, so that we can use the I2C hardware, instead of trying to bit-bang the 1-wire interface.

    abkirchhoff