MBDT Toolbox - DSPI Configuration appears to sometimes forget to de-assert CS after DSPI Master Transfer is complete on SPI Config 1.
MPC5744P Using NXP Dev board and associated Motor GD board.. a SPI (0) is configured for GD3000 communication (which isn't used after initial configuration), and an additional SPI (1) on which the problem appears, is configured to talk to a Shaft Speed sensor (Infineon TLE5012B). The CS gets asserted (low) in the code (DSPI_UpdateCS), but relies on CS being de-asserted at the end of the Master transfer (DSPI_MasterTransfer).
I have run the configuration at 1Mbps or 2Mbps, with same effect. Regular (1ms periodic) short burst reads from the TLE operate correctly, but show a failed CS de-assertion at approx 413ms periods that persist for approx 15ms (while 15 other reads are attempted). Configuration of SPI 1 is set for 'continuous mode', as TLE5012B uses CS edge to 'strobe' information capture, and MBDT cannot otherwise control CS line to NOT be rescinded between bytes of message.
Only 1 CS is configured on both SPI Config 1 and SPI Config 0.
Attached screen shot shows 1ms bursts and then a long 15ms CS assertion at center screen (SELECT legend)
Any clues where to look, as the erroneous CS causes all sorts of erroneous values to be read.
I suspect a failure to properly handle end of transfer interrupt somewhere.
The 413ms repetition period is purely 'time-based' and bears no relation to rotary speed/commutation etc. hence it unlikely to be influenced by anything other than other periodic tasks.
Moving the Matlab scheduler timing (except of primary 100us ADC_CTU_PWM driven tick) of all other tasks ( which are at prime numbers of 100us, in general at approx decade reduction (so 0.0001, 0.0011, 0.0101, 0.1009 and 0.2003s) ) makes no apparent difference.
Regards,
Stuart
