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.
I will investigate this strange behavior. Have you tried at lower frequencies (lower than 1Mbps that you already mentioned)? I will get back as soon as I find the culprit.
I may need to correct my previous statement regards 500Kbd, as I was changing many other things in the build along with this experiment... so no longer confident the answer was right.
I have this morning being trying a number of different baud rate configurations for SPI1 to try and track the problem down... whilst changing NOTHING else., and keeping the LSA clearly targetted at this issue.
I am unsure of the SPI clock variability or baud rate selection steps (the NXP MBDToolbox doesn't restrict), so doing baud rate selection blind... to see if there is a critical breakpoint.
This morning's results so far... with a largely binary chop approach
1000Kbd - Problem
750Kbd - Problem
500Kbd - No Problem
625Kbd - No Problem
675Kbd - No Problem
700Kbd - No Problem
725Kbd - Problem
712.5Kbd - Problem
706Kbd - Problem
703Kbd - No Problem
704.5Kbd - Problem
703.75Kbd - Problem
703.375Kbd - Problem
703.188Kbd - Problem
703.090Kbd - No Problem
703.135Kbd - Problem
703.115Kbd - No Problem
703.125Kbd - No Problem
703.130Kbd - Problem ** - See below
703.127Kbd - Problem
703.126Kbd - Problem
703.125Kbd - No Problem
600Kbd - No Problem
650Kbd - No Problem
In all cases where there is a problem above, CS remains asserted (low) for approx 120ms, (even though data queued/sent during that period); and the interval ( from start of one long CS assertion and start of new long CS assertion) every approx 425ms; irrespective of Baud Rate setting.
[**At exactly 703.130Kbd the CS asserted pattern is different - spending most of its time asserted in no particular pattern with CS periods from 25ms to 175ms, even though data transmission are still periodic (at 1ms intervals) at 80bits in length (as they have been throughout the test).]
Obviously none of these were long duration tests, but teh result appears pretty stable <=703.125Kbd Good, >=703.126Kbd Bad.
So that should have identified it down to a bit cycle of 1.422222us recurring as distinct from 1.4222202us or about 2ps difference!
I probably used up 0.02% of my target life with all those erase/reprogramme cycles!
Thank you for this in-depth analysis. I think is very useful & interesting.
I'm not a hw expert but it would interesting to check if these failures are within the specs for the MPC5744P: https://www.nxp.com/docs/en/data-sheet/MPC5744P.pdf
Furthermore, the Simulink generates only the parameters configuration structures based on user settings. Then those structures are passed down to NXP SDK driver that handles the SPI. At this point I'm not sure if this is a SW or HW issue.