Si5340 debugging

[jmatyas]

• unable to communicate with Si5340 on I2C bus
• if nRST not driven, it floats up to 2.15 V
• every possible address from 0 to 255 has been tried out - no success
• after the master starts the transmission and sends the device address, a NACK is detected - always

Since, according to its part number, the Si5340 installed on Fast Servo is already pre-programmed, it is suspected that its voltage thresholds are incompatible with the 1.8 V from the SoM. It is currently being investigated:

• [x] remove SoM from carrier
• [x] temporarily short 1.8 V from SoM with 3.3V so the SMPS generates all of the power supplies
• [x] temporarily desolder pull-up resistors from the Si I2C lines
• [x] pull-up lines to 3.3 V
• [x] try to communicate with Si with the use of external I2C master controller
  • [x] if successful, change NVM register value, so Si I2C voltage thresholds and communication switches to the one compliant with 1.8 V. BE CAREFUL!!! The Si5340's NVM is programmable, but only ONCE

EDIT: In general, Si5340 NVM is programmable up to three times. Fortunately, it is possible to find out how many times it has been already programmed. One just needs to read a register that contains this information (see: register map section of the reference manual)

[jmatyas]

Suspicion regarding I2V voltage thresholds confirmed. Switching I2C Bus voltage to 3.3V allowed to communicate with Si5340. Contents of the register under address 0x0943 confirm this.

Suggestion regarding next release:

• since there may be problems from time to time with such matter, an idea that is worth considering is to place I2C bus voltage shifter between SoM and Si5340 from 1.8V to 3.3V (it would need further investigation and datasheet reading, however, a quick test revealed that after setting Si5340 I2C voltage thresholds to 1.8 V, communication on bus powered from 3.3V was still possible)

[kaolpr]

Nice catch! Good that things start to look reasonable ;-)

Have you tried reprogramming Si5340 to use 1.8V?

I believe under normal circumstances this should not be a problem, as 1.8V is a default option. Using shady source for components is not a reason to complicate the design.

However, as shady sources may be our only option these days, we could add a pad for goldpin header for programming Si5340. Then manufacturer can introduce appropriate programming action into the testing procedure (before assembling SOM).

[jmatyas]

Have you tried reprogramming Si5340 to use 1.8V?

Yup. I burned this configuration to its NVM. However it has not been yet tested with the bus voltage pulled up to the 1.8 V.

However, as shady sources may be our only option these days, we could add a pad for goldpin header for programming Si5340. Then manufacturer can introduce appropriate programming action into the testing procedure (before assembling SOM).

That makes sense, but bear in mind, that pull-up resistors on this bus are placed on the Fast Sevro carrier, not on SoM. What's more the 3.3 V power won't start, if it doesn't detect enable signal, which in this case comes from SoM.

[jmatyas]

Have you tried reprogramming Si5340 to use 1.8V?

Yup. I burned this configuration to its NVM. However it has not been yet tested with the bus voltage pulled up to the 1.8 V.

I tested the I2C connection on hardware with SoM mounted. Works like charm

[kaolpr]

It seems that Si5340 is more available now and we can assume it will be set to defaults. However, I suggest we add test points for the purpose of reprogramming in case of someone needs to recover from erronous programming.