Part Number: AM625
Tool/software:
I found a weird race condition bug when using the SPI in a freertos environment. By enabling tracing, I noticed that if the ClockP_timerTickISR is interrupted by the udma_eventIsrFxn, then some memory seem to get corrupted, e.g. the freertos task name is zeroed out.
I suspected stack overflow at first, but I’ve tried increasing the stack sizes of all tasks (including idle and timer svc), but it did not seem to help.
I also tried enabling a data breakpoint on the freertos task name, but I couldn’t get it to hit (which I found weird - I verified that it worked by watching a different global variable, and I could see it was 0 by reading the memory at that location (I might have made a mistake somewhere though)).
Changing the udma interrupt priority (which is hardcoded(!) in source/drivers/udma/udma_event.c) from 1 to 10 fixes the problem (as the timer interrupt is hardcoded to 9). This is interesting as it implies that udma_eventIsrFxn can get interrupted by ClockP_timerTickISR but not the other way around. Obviously not a great solution though..
In our code, the SPI acts as a slave, we transfer 48 blocks of 3k bytes back to back @ 50 MHz, we use callback mode and start the next transfer (by calling MCSPI_transfer) from the ISR. We post a semaphore for each block received. By doing this repeatedly, we are able to trip it up within a couple of minutes. I would expect the same result if running as master, so hopefully it is easy to reproduce.
Regards,
Endre
