RM46L830: RM46L830PG

Hi Gary,

Gary Holder said:

I notice that if I momentarily short the MOSI signal, the SPI port stops sending data. The SPI clock stops and no more data.
Our CS lines are manually controlled in software and they keep going as normal. 

Do you mean,

if you are using small length cable then SPI stops communication? is my understanding correct?

Is it working for long length cables without any issues?

I don't see any issue like this before.

You can also find some working examples on SPI in below FAQ, you can refer them once:

(+) [FAQ] TMS570LC4357: Examples and Demos available for Hercules Controllers (E.g. TMS570x, RM57x and RM46x etc) - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

--
Thanks & regards,
Jagadish.

Jagadish,

Thanks for the help. Sorry for my confusing question. I will try to clarify below. I am investigating an issue with a legacy device in our company.

When I say "short" this means that the MOSI signal gets connected to ground for a few milliseconds. When this happens, the SPI stops working. It appears the SPI peripheral in the Hercules got reset or something latched up. I know connecting MOSI to ground is something that should not happen, but I was hoping to understand what mechanism in the Hercules processor would shut down the SPI port if the MOSI GPIO is momentarily grounded. Is there some type of Error bit that gets set? Is this a design feature of the Hercules? 
I can momentarily connect MISO to ground, and the SPI keeps working after releasing it from ground. I can momentarily connect the SPI clock to ground, and the SPI keeps working after releasing the clock from ground. 
I am just wondering why when the MOSI output is momentarily grounded the SPI stops working?

I am investigating why periodically our device can run for days and all is OK. However, sometimes the unit gets a software error because it stops getting data from the SPI. I am wondering if maybe something is causing the MOSI to see a connection to ground.  One thing I do see in this design is that the Hercules MOSI signal, SPI clock signal, and the Chip select signals all have 1000pF caps on them. I assume these were added for EMI at some point in the design process. My theory is maybe these caps are causing the SPI to stop working just like when I purposely momentarily ground the MOSI pin. 

Is there any way to get help on this issue. I need to understand the mechanism that causes the SPI1 SIMO output to reset the SPI port if it sees too much current. The other two SPI ports do not do this. So, I think it has something to do in the pin's location inside the processor die. Maybe a high current spike causes something to get corrupted in the SPI registers or maybe the power supply monitor gets triggered. I need to speak with someone at TI that understands the hardware of this processor. 

Hi Gary,

In Hercules devices (including RM46x), i never saw this behavior before, so can you please more details so that i can trigger this issue at my end and will verify the behavior.

1. How you are operating RM46x, master or slave?

2. What is the other end device, for example if RM46x is master then what is the slave device in your testing's?

3. What kind of data you are sending from RM46x? how frequently you are sending? similarly what data you are sending from the other end device of SPI?

Please provide these details so that i can trigger this issue at my end and can analyze further.

--
Thanks & regards,
Jagadish.

Thanks Jagadish, for the reply.

We are using the SPI1 as the Master. We are using pins 93 (MIBSPI1SIMO), 94 (MIBSPI1SOMI), 95 (MIBSPI1CLK) , and 105 (MIBSPI1NCS[0]. 
The software manually controls the CS pin as a GPIO. 

The SPI clock is at 1.8MHz. The SPI signals go to a connector on our main board. A 4 inch long twisted pair cable connects to another board that has an ADS1256 analog to digital converter. The ADS1256 has 1nF caps to GND on the SPICLK, SIMO, and the CS0 pins. We are accessing data to and from the ADS1256 about 3000 times per second. 

The SPI1 will periodically shut down as if it lost its settings. This is very rare. Sometimes the system will run for days or weeks and not have an issue. 

The only way I can quickly reproduce the issue is by quickly connecting the SIMO pin to ground. Just a quick touch of the SIMO pin with a lead wire connected to ground will cause the SPI1 clock to stop. This is turn causes the software to error because of bad data. 

I can also increase the frequency of the SPI1 reset by increasing the values of the 1nF caps.

I am curious if you can setup SPI1 on a development board and get similar results by just quickly connecting the SPI1SIMO pin to GND. 

My theory is that the 1nF caps are drawing enough current when the SIMO pin transitions that it sometimes causes the SPI1 to get reset inside the Hercules or maybe just one of the SPI1 registers gets corrupted.

We also use SPI3 and SPI5 locally on the same PCA board as the Hercules. We can quickly connect their SIMO pins to ground and they continue to work OK.   Maybe the location of the SPI1 SIMO pin on the Hercules die allows for some registers to get corrupted if too much current is drawn on the pin. 

Thanks Jagadish,

I was not aware that his bit would shut down the SPI port until cleared. I believe this is the issue we are seeing. I will get our software team to look at this and confirm they can clear this bit and continue to communicate afterwords. I will report back here the results. 

It's interesting that the processor manual mentioned capacitive loading as a possible cause. The answer was staring me in the face and I did not see it. :)

Thanks again for all the help. 

Hi Gary,

It's my pleasure!

Please let me know if it solved the issue or not. I did practical testing, and it solved the issue.

--
Thanks & regards,
Jagadish.