TMS570LC4357: Timing issues with MibSPI #1 interface

Hi Carlos,

I started to be working on your issue and i will provide an update very soon.

--

Thanks & Regards,
Jagadish.

Hi Jagadish, thank you for looking at this issue.

We have run more test and we found the following (in case it helps you to understand better what's going on):

We have a scheduler which contains one function to trigger the transmission (enable TG) and another that is called later to read the received data. Apparently, the gap between each sent data packet is the duration of the scheduler frame. For some reason when the TG is enabled it sends only one data packet.

if we add a loop to wait for the TG transfer complete flag all the data is sent as expected, the thing is that the functionality we are looking for is to get the TG enabled, let the CPU to take care of other tasks and then try to read when the data is supposed to be available. 

Regards,

-Carlos.

Hi Carlos,

Carlos Guerrero said:

We have used other of the available buses and had no problem sending the data packets, but when using SPI #1 the following happens

I don't get this point, are you tested with any other SPI's? is it working properly with other SPI's and having problem with only SPI #1 instance?

Carlos Guerrero said:

~14ms between them, so transmitting the 27 packets is taking a lot.

This much of delay should not happen with SPI, how can you make sure that it is not slave delay? And controller is acting like SPI master right?

jagadish gundavarapu said:

I don't get this point, are you tested with any other SPI's? is it working properly with other SPI's and having problem with only SPI #1 in

Correct, we have developed other drivers using SPI#5, SPI#2, SPI#3 and we are having issues only with SPI#1.

jagadish gundavarapu said:

This much of delay should not happen with SPI, how can you make sure that it is not slave delay? And controller is acting like SPI mast

Yes, controller is the master and acts like it. But in latest test we found that this delay is dependent on how often we enable the TG, the problem we are facing is that every time we enable the TG (trigger transmission) the bus doesn't send all the packets that are part of it (27 in this case), it only sends one. So, since we are calling the trigger function every 14 ms we are seeing one packet transmitted at that rate. However, the expected behavior is to get all the packets transmitted every time the TG is enabled, right?

Hi Carlos,

Can i get a minimal version of your code with only SPI functionality? So i can easily test and debug your issue at my end.

--

Thanks & Regards,
Jagadish.

Hi Jagadish, 

We created a small application using Halcogen to get a program that only runs the SPI for our application, we found the SPI was working fine there. 

That's why I didn't send you the minimal version you requested.

However, in our final application we found out why the SPI #1 was having issues. For safety/certification we are explicitly disabling all modules that we are not using and apparently when we disable I2C the SPI starts having some timing issues.

Hi Carlos,

There should not be any dependency for SPI with I2C bits,

Did you check that whether any other part of the programming also using the macros you mentioned?

--

Thanks & regards,
Jagadish.

Hi Jagadish,

Turns out our logic to disable the modules was incorrect and we were actually disabling the MIBSPI1 module instead of the I2C1 module.

Knowing that, however, we wonder how we were still able to interact with the module while it should have been disabled...

The MIBSPI1 was disabled by mistake, setting bits 8 and 9 (Peripheral select 2, quadrants 0 and 1) in PSPWRDNSET0 register for PCR3 to disable it. While the MIBSPI1 peripheral didn't work as expected, it did work partially where we were able to transmit data, which is surprising considering it should be disabled... At this point, we're wondering what using these PSPWRDNSET registers is doing. Is there anything else required to disable the module?

Best regards,

Marc-André Rhéaume said:

actually disabling the MIBSPI1 module instead of the I2C1 module.

If we did that means, MIBSPI1 should not work anymore right?

Marc-André Rhéaume said:

Knowing that, however, we wonder how we were still able to interact with the module while it should have been disabled.

Can you please verify exactly which bits of the registers are affecting with the commented lines. I mean verify exactly which bits states are changing when we uncomment and comment the lines. Better to do this in debug mode, is that possible?

Then we will see the definition those bits.

--

Thanks & regards,
Jagadish.

Hi,

Closing the thread because of not hearing back from so long.

--

Thanks & regards,
Jagadish.