AnsweredAssumed Answered

DSP SPI Config 1 not de-asserting CS at end of Transfer (periodically)

Question asked by Stuart Jobbins on Sep 11, 2019
Latest reply on Sep 24, 2019 by dumitru-daniel.popa

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.