MSPM0G3507: Arm-based microcontrollers forum

Siegfried Buechele

Part Number: MSPM0G3507

Dear support team,

for my application I need SPI in SPI_MOTO3_POL1_PHA1 mode. From principle behaviour is correct.

But initial behaviour is ugly, driver first switch gpio mux to spi Interface then the spi Interface is configured.
This leads to a drifting clock signal from high in direction of zero.

See appended screenshot from oscilloscope, green signal channel.

Depending on voltage drift level this leads sometimes in case of init process to an useless read process.

So my workaround, is doing first time a dummy read, and throw away the result.

Is there a plan of TI to improve driver behaviour?

Second part of question, is there a plan to improve time between calling SPI_transfer, and real action on bus.

When I see the huge time between setting cs low (pink) and starting transfer on bus, this makes me ugly.

It is better in case of normal run, but when I see the call hierarchie and all the other stuff not really funny.

Code example:

DL_GPIO_clearPins(GPIOB, DL_GPIO_PIN_6);

transferOK = SPI_transfer(controllerSpi, &transaction);

DL_GPIO_setPins(GPIOB, DL_GPIO_PIN_6);

Regards

Siegfried

over 1 year ago

0 Dylan OBrien over 1 year ago

TI__Genius 16000 points

Hi Siegfried,

Are you using a launchpad and one of our code examples, or are you using custom hardware and/or custom code?

I ask because during my time working with our SPI code examples, I have not seen behaviors like what you are describing and showing in your images. While I can't recall the exact time between CS-low and the start of data transmission, I do not think it takes 30 or more microseconds to start a transmission.

Additionally, I am not clear on what you mean about the useless read taking place sometimes when the voltage is drifting down, you mean that the device captures some, but not all of the data transmitted, rendering the data captured in the buffer useless?

Are you running an RTOS or is there some other process occurring here that could slow down the execution of the code, like having many repeated interrupts?

0 Siegfried Buechele over 1 year ago in reply to Dylan OBrien

Prodigy 110 points

Hi Dylan,
yes I'm using a lauchpad, with code example freertos and spi controller. The one which sends and receive a data packet for 10 times.
I modified it, so the transfer size is just two bytes at 2MHz with manual setting of CS signal.
External IRQ is disabled after your suggestion. As far as I have understood the configuration I believe the cpu is running with 32MHz.

The time is measured between this two lines of code.

DL_GPIO_clearPins(GPIOB, DL_GPIO_PIN_6);

transferOK = SPI_transfer(controllerSpi, &transaction);

DL_GPIO_setPins(GPIOB, DL_GPIO_PIN_6);

It is in context of a task, what me wonders is the huge number of irq disable and enable calls during SPI_transfer call.

I measured the time with oscilloscope and measured values between 15 and 20µs.

Second screenshot shows init process. Before clk pin is configured high, then mux is switched to SPI this whole code needs round about 80µs till real start of device.
Could it be a time domain problem between SPI and CPU core?

>>Additionally, I am not clear on what you mean about the useless read taking place sometimes when the voltage is drifting down, you mean that the device >>captures some, but not all of the data transmitted, rendering the data captured in the buffer useless?

This drifting during init process causes sometimes an invalid clock glitch which leads to wrong data. This behaviour only occurs in case of startup.
But as I see in your driver code there are several error case handlers, which could lead to a restart of the SPI component so I am a little bit nervous about things like that.

Yes I am running freertos, no real other active process, IRQ of external IO Pin is disabled for test purposes even it wasn't active.
But what me wonders in the example, there is an DMA configured but ransfer is running in polling mode.
Perhaps there is an pending DMA IRQ?

Regards

Siegfried

Additional Info: When working with call back function and trying to avoid blocking mode the times are getting greater, especially after transfer.

After doing some further investigations, and seen the cycle overhead for freertos, I have measured the time between callback handler and task getting active again, these are round about 22µs. So from my personal view point the problems are caused by using freertos.

Done additional Tests with pure DMA Process without freertos.

Obviously a practical value.Problems seems to be based on freertos.