I've been working on an issue for several days now, and I'm at the point of giving up and finding another hardware solution for my needs. In short, everytime SPI_transfer() is called after the task is posted, the TIRTOS HWI Handler is invoked resulting in a spin (or a system reset with RESET_ASSERT defined):
do
{
tmp = spi_readByte(0x00002E00);
Semaphore_pend(gwSemHandle, BIOS_WAIT_FOREVER); /* wait for gw tick */
} while((tmp&0x01) == 0x00);
Notes:
- gwSemHandle is posted by a 1s-periodic hwi
- inside spi_readByte() is essentially setting up an SPI_Transaction and executing SPI_transfer()
- issue is nonexistent if Semaphore_pend() is commented out and everything works fine, but the loop is far too quick for my needs without it; ideally would want to utilise semaphores to preserve task execution priorities
- Task_sleep() in place of Semaphore_pend() results in a crash as well
- task stack size is set at 1024, and peak usage with ROV is at 368 during debug
- right now I only have access to an XDS110 debug probe, and stepping through the code the errors/debug probe panic happens at different points in the library, but always under the SPI_transfer() stack; more often than not the panic occurs at UDMACC26XX_disableAttribute() execution
- source code is loosely based on dmm_154sensor_remote_display_oad_app example, using SDK V3.40.00.02
- compiler version is TI v18.12.5.LTS
- using CCS 9.3.0.00012
