I've got a problem with the SSP 1.2 beta framework for SPI. I have it set up in a pretty normal sort of way as far as I can tell. I do a write or writeRead (haven't attempted a read because you have to write to read) and it goes through all the bus transactions (e.g. writeRead 20 bytes, does all of them) and then pukes.
stack walkback is:
So what it's doing is something with the end of the transaction.
The CS lines have not come back to life yet but all the bytes have been written out (thread #4 is the thing doing the writeRead call:
g_sf_spi_device0.p_api->writeRead(g_sf_spi_device0.p_ctrl, IDbuf, IDbuf, sizeof(IDbuf)/4, SPI_BIT_WIDTH_32_BITS, TX_WAIT_FOREVER);
It'll do this with a straight write too.
I've increased the stack on thread #4 to 2000 bytes (all the RAM I've got left, which is a problem) to no avail.
I've got stack checking turned on (TX source loaded). It's not bitching about anything
When I check RTOS Resources, it is showing a stack of that thread at around 600 bytes used. No thread is showing stack overrun.
Pointers are strange in the structures.. Basically, group_prt in _txe_event_flags_set() is showing @ 0x15dc1242 (I've seen this at like 0xbxxxxxxx) so these are probably out in lala land somewhere (These should all be pointing in FLASH as far as I can figure). Not sure how you'd even get this in the wrong spot other than stack corruption.
In sf_spi_callback(): this pointer is generated out of: p_ctrl->p_bus->p_sync_eventflag
p_ctrl is kinda off the rails somewhere. Not reasonable things at all. It is derived from rspi_cb_data.p_context which *should be* 0x200278b0 <g_spi0_ctrl>
so this is pointing to a stack overflow in thread #1 (in trace this is tx, not actual threads)... so where do I change the stack size for that any why isn't this reporting a stack overrun?
