RM48L952: SPI communication with LTC6820, LTC6804

If there is any extra information you need to help with this issue, please let me know.

Hello John,

Although I haven't had the opportunity to review your code just yet, can you provide more information regarding your SPI setup? i.e., is the RM48 a master or slave? Have you had a chance to look at the signals coming from your external components to the RM48? If the external bit stream is held high, the RM48 will naturally receive all F's and there would seem to be an issue on the external component transmission. If the received signal is toggling with a valid SPI message and still you are seeing all F's there could be an issue on the RM48 we need to look into. Also, have you confirmed the external device is receiving the proper information? You may need to probe on either side of the isoSPI converter to insure the full data path.

Chuck,

Thank you for replying. I'm using the RM48's SPI2, which is in Master Mode, which I set using Halcogen. I have been able to prove that the external components (the LTC6804 and LTC6820) are working properly, as I can send and receive messages properly using LTC's test GUI.

I'm using LTC's isoSPI bus analyzer to read the SPI messages received by the LTC6804, and when I try to use the RM48, no SPI messages even appear on the analyzer. What is interesting though is after when no program is running on the RM48, but it's connected to the LTC6820, the bus analyzer reads all FF's being sent by the RM48 to the LTC6820.

Please let me know if any of that helps.

Johnny

So, something else I've discovered while playing around with this.

I have yet to figure out the exact Halcogen settings for SPI2 that controls this, but sometimes instead of receiving all FFs in the receive buffer, I instead receive the the message I have sent out. It doesn't appear to be the LTC6804 sending it back to me, as I have removed the wiring and still gotten the same thing.

Any thoughts on what may be causing that?

In addition, I have tested out the Master-Slave SPI example program provided by Halcogen (with SPI1 as the Master and SPI2 as the Slave), and I have gotten the same results (the RX buffer for SPI1 is all F's). I've followed the directions in the comments on how to set the SPI driver in Halcogen, but to no avail.

Any help with this would be greatly appreciated.

Hi John,

Apologies for the delay in getting back with you. I will have a look at your code and get back to you. Is the code attached at the beginning of this thread still representative of your active code?

The only major difference is that I'm using SPI1 instead of SPI2. This is because I need to use Ethernet ultimately for this project, which is muxed with SPI2, so I can't use both. I've gotten the example SPI code you guys provide to work in doing that, but communication with the LTC6820 still doesn't work.

Hi John,

What do you have VDDS configured to for the LTC6820? Output to the Hercules device needs to be between 3.0 and 3.6V since the IO on Hercules devices are not 5V tolerant.

If you are able to communicate between SPI1 and SPI2, there is, most likely, no issues with the code. You mention that when there is no code running on the RM48 that you see all F's on the isoSPI Bus analyzer? Is the RM48 held in reset? What is the source of the spi clk if there is no code running on the RM48 and it is the master?

Have you discussed this with the Linear application engineers? There could be something missing from the interface between the isoSPI and the standard SPI on Hercules that I would be unaware of. I would believe they should have greater experience in interfacing their device to a standard 3.3V SPI and might be able to get to a solution quicker.

The battery I'm using to power the LTC6820 via VDDS is 4V. So you're saying I should use a power source with lower voltage?

Hi John,

According to the LTC6820 datasheet, this means that VOH = 0.8*VDD = 3.2V and VOL = 0.2V max so the voltage levels should be fine.

Looking at the LTC6820 datasheet, it has the below diagram of a typical implementation.

Does this reflect your implementation as well with the Hercules device being the master? Also, are there any pullups/downs on any of the signals at the MCU?

This is the setup I'm using. I should have been a bit more specific, I'm using the DC1941D, which is a demo board for the LTC6820. The above figure is from the DC1941D's datasheet.

As for pullups, I have them enabled on all SPI signals for the RM48 via the Halcogen SPI1 Port Tab.

Just as an update, I'm supplying the DC1941D with 3.3V rather than the 4V power source. The isoSPI bus analyzer is showing stuff coming through, though it's very bad data. I'm trying to make sense of it, to see if it's shifted somewhat or something similar.

Johnny.

John,

Can you check the phase and polarity settings to make sure the two nodes match configuration? Also, you should be able to monitor the data lines with a scope to see if you can capture a transmit sequence. This will show if the data at the Hercules pins is as expected and if they match what you are seeing with the isoSPI analyzer tool you're using assuming it connects somehow to the EVM.

Hi John,

Glad you were able to narrow down the configuration of SPI. Unless there are pin conflicts, there isn't any other blocking mechanism or dependencies between the two IPs. They are even on different clock domains within the device. Can we close this thread and open another on the new issue? It would be best from a tracking and search perspective.

Yes, I will open this up in another thread.