Possible I2C/SPI threads interaction of some type

I've got another oddity here using SSP 1.2.0 that I can't explain at all.  Looking for some ideas on how to attack looking for this problem.

I've got 2 (well more than that, but these are the ones I'm interested in) threads running: A that talks to a pressure sensor out on the I2C bus using shared I2C framework on sf_i2c.  It talks to this thing every 100mS.  Thread A is running pretty low priority.

There is a thread B that talks to 2 audio amps on the same I2C bus (shared framework sf_i2C) for control of it.  This thread also uses the SPI framework to do synchronous reads of the SPI memory.  Thread B is running very high priority.

 

Top two traces are I2C SDA and SCL (CLK is at around 400KHz)

Bottom 4 traces are SPI bus MISO, MOSI, CLK and CS top to bottom.  SPI is running @ 2MHz (I want to go waaaay up from there but)

The BLUE circles show thread A talking to the I2C bus.  It's a 4 byte single read transaction.

The GREEN circle is thread B talking to the audio amps turning one of them on.  Write transaction of 2 bytes.

The RED circle is the SPI bus hanging.  I get here with the SPI doing a hard fault in an overrun condition.

Closer detail of this:

CS low to the I2C traffic is always on the order of 20uS give or take a couple.  Always get out something like 150-200 bytes in this last try (it's reading 512).

walkback is as follows:

The even in the sf_spi_callback() is SPI_EVENT_ERR_OVERRUN.  In the past I've turned the clock on the SPI system down and it started running better but this is at 2MHz now and with this S5D9 running at 120MHzth, is really aught to be able to cook without overrun. 

So there are two problems here, overrun and blowing up because of it.

Looking at stacks, the thing is showing max stack a long ways from the size of the stack.

The line causing the serious fault is:

where p_bus is pointing off at 0x4b570bd (a little over the top of RAM)

It's interesting.  It's *always* this juxtaposition of I2C to SPI that is present when it explodes.

  • Hello,

    Are you using multiple RSPI instances in the project? If that's the case, an attempt at opening second instance would fail and make first instance malfunction in the ISR (which I believe is what you're seeing, judging from the call stack). This problem is fixed in the upcoming SSP patch (no release date yet, however).

    Regards
  • In reply to Renesas Karol:

    only single instance of RSPI. I2C there are several of those spread across 2 threads.
  • In reply to rjl:

    OK, so I had a thought of experiments to run this morning. Editing code taking this, that and the other thing out of the code. I got it working and thought I had the smoking gun but as I added code back in to do A-B-A testing, it kept working. got it all back to the "same point" where it was failing and it works fine.

    That tells me that either A) the particular module in question had some sort of miscompile/alignment/screwy thing that the recompile of that fixed or B) that in the recompile I've changed position of some code somewhere that is causing the problem to be somewhere else (or masked). I'm betting the later.

    I'd dismiss this but looking back at some old notes on a slightly different problem I was having and solved, I noticed the same signature.
  • In reply to rjl:

    Turns out that I didn't put *all* the code back in and I can get this to crash at will.

    It doesn't have anything to do with I2C but something to do with timing of messages somehow. Will look into it further.
    There is another thread that popped up (renesasrulz.com/.../26447 that has similar issues on UARTs.

    This *does* leave one issue: When I do get the OVERRUN (why is another problem) in the SPI driver is crashes with that walkback above. This has to be some sort of bug in the SPI driver.
  • In reply to rjl:

    Hi rjl,

    Despite the fact that max. stack usage is a long way from the size of the stack, can you assign more memory to SPI/I2C threads? Maybe setting higher priority (i.e. lower number) for SPI thread and SPI-related interrupts will help your application avoid overrun errors?

    Regards,
    adboc
  • In reply to adboc:

    I had already done the main threads with larger stacks (Where TraceX says I overran it) and SPI is running at priority 0 for TX and RX (2 for error).
  • In reply to rjl:

    So there are two problems here: the first something that is causing the over run and the second the over run doing something bad. I can't fix the later.

    The former has something to do with this thing then talking out to the LCD (the I2C thread throws a message which tells the GUI thread to update and icon which causes the overrun). The GUI thread is running at priority 10.

    What I ended up doing here was to bandaid this and stop updating that portion of the screen (other portions that change text update fine!?!?!) when I'm pulling SPI. Not elegant by any stretch but expedient.

    So the one thing I can't do something about is the handling of the overrun. That causes segfaults because of some pointer overrun somewhere during that handling.

    I can attempt to increase the stack size on those threads and see if that helps it, but I'd be really skeptical that it would.
  • In reply to rjl:

    Hello rjl,

    Are you using SPI-driven display on your board? SK-S7 and PK-S5 use SPI only to initialize the display with correct settings for gamma, stride and interface - video data is pushed out to the display using DE interface with RGB565 format.

    Regards
  • In reply to Renesas Karol:

    no, that display is like the S3 dev kit one: it uses the BUS system to communicate.
  • In reply to rjl:

    Hi rjl,

    If you set lower frequency for SPI, do overrun errors disappear? Are you running the application on PK-S5 or your custom board?

    Regards,
    adboc
  • In reply to adboc:

    This on my own board...

    I've lowered the frequency in the past and it has reduced or eliminated the overrun errors. Still for a 120MHz part that has issues keeping up with 2MHz SPI.......

    But the main problem here is the crash when it *does* overrun. Looks to be a pointer that's off in the ozone in lower SPP layers when it happens.

    I've got a bandaide over the getting of the overrun but can't fix the fallout when it does happen.
  • In reply to rjl:

    Hi rjl,

    Does the SPI driver use DTC transfer driver? If so, please try removing it.

    Regards,
    adboc
  • In reply to adboc:

    if I removed it, I can turn that SPI up to 8MHz and it doesn't get overruns. That's never happened before so I'm thinking this is better done without DTC.
  • In reply to rjl:

    Hi rjl,

    Does your project use more DTC transfers? Maybe other modules occupy DTC and thus SPI cannot fully use it.

    Regards,
    adboc
  • In reply to adboc:

    clearly that's what's going on here with DTC.. I've dropped DTC use on SPI and life is better. Strangely enough. So this would only be using ISR traffic at this point, yes?

    so about the crash when it gets an overrun....