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.
In reply to Renesas Karol:
In reply to rjl:
In reply to adboc: