Hello,
This is not a Keil specific question - my apologies for that, but I'd like to know whether you encountered problems related to program stability when using SSP0/1 peripherals (in SPI mode) of the LPC2478? I have a nearly finished product here that uses that peripheral to deliver data on a trace of a few centimeters at moderate baudrates (slowing down does not seem to help, and either way it is not an option). What I see are occasional programs failures that occur while such a transfer is in progress; I do not know exactly what the source is, but it always happens while a transfer is busy, and the link register makes no sense (or, if it does, it points to the idle task of my OS. Obviously, something went wrong before context switch). A built-in trace I wrote makes no sense either (it details interrupts, context switches etc.). I even created a special revision of the software that does nothing but such transfers and it indeed dies after 50 attempts on the average. Do you have any suggestions, recommendations etc.?
Is it using DMA or FIFO? What about ISR?
I haven't used LPC24xx but should be same peripherials as in LPC23xx. No problems seen. Not using any OS-supplied code. Sometimes using SSP0 and SSP1 concurrently. At least one of them in use almost constantly at quite high speed.
What features are you using when running your SSP? Are there any source events that you haven't caught by the ISR, so the ISR starts to run continuously and kills scheduler or some other function? DMA read from invalid address? DMA write to invalid address? Incorrect peripherial clock frequency?
I do not use DMA (I enabled it once without a significant performance gain so I dropped it). The peripheral has a hardware FIFO of 8 frames (bytes in my case). I have tested the SSP within the bootloader - it can also transfer data - and I have not encountered the problem there so it must be a (my) software issue! The clock is much slower that the maximum setting allowed for slaves (1/12 of the peripheral clocks). And besides, slowing down does not help... The ISR handles 1 or 8 frames, and has provisions to guard against buffer overruns. The failure occurs at randoms times. Stack usage should be stable, but I'm checking that now as well.