MAX22192_EVKIT_B Daisy chain mode slave 2 is not responding.

From your timing diagram I believe you are addressing the ICs in reverse order. Here you attempt to write 0xFF to address 0x20 of U2 which is MAX22190 and does not have an addressable register at 0x20. If you refer to figure 13 (MODE 3, DAISY-CHAIN WRITE) in the datasheet you can see that the data associated with the first instance of the CLK is for the last device in the chain not the first.

I hope this helps address the problem you're seeing, please let me know if the problem persists.

Hello   thank you for your response,

Yes, you are right. The first packet is intended for the MAX22190, but I am receiving a MAX22192 packet in the first cycle of the frame. To verify this, I provided input to the T1 and T2 terminal block, which belongs to the MAX22192. As you can see from the packet above, the response is reflected in the first cycle.

To verify wether 22190 is working i used the USB2PMB2 to check it (Mode 1), and it is working fine there.

Ah I see what you mean, you are receiving U2 input data first when you expect U1. But it doesn't look like you have the jumper settings correct for daisy chaining, please set the jumper positions by the diagram given in the evkit software 

Hello   The test setup in the figure i have taken during testing 22192 alone, yes iam using the ev kit software for jumper configuration.

Hi Sarun, I must correct my previous statement while in Daisy chain mode the MAX22192 will actually act as the last device in the chain not the first as it simply passes the isolated SDI signal to the field devices without acting on what it receives from LSDI but instead the internal shift register is received from FSDI which is connected to SDO of the previous field side device. So therefore the first set of return data will be from the MAX22192. Sorry for any confusion that created. Figure 13 in the datasheet demonstrates this more clearly

Hello  ,Sorry for the delayed response. I got a bit confused and tried probing on the field side of the 190 (X2 connector). There, I was able to get a reading, but on the X1 side, the 190 response is not coming through. I am planning to do this on another custom board which I have yet to receive.

Hi Sarun. Are you still experiencing the same issue? If so can you capture the signals exactly as in figure 13 of the datasheet so I can get a clear picture of what the problem is. Include the two frames with 64 clock cycles in total as before. Can you also label the signals as LCS, LSCK, LSDI, FSDI, LSDO.

Hello  ,thank you for your reply. Yes, I am still facing the same issue. Currently, I have stopped testing it for now. As I mentioned earlier, the behavior is totally confusing, iam planning to test this later on a custom board with the MAX22196. Regarding the waveform i will provide as you requested. 

Okay I will wait for you to test it on your custom board. Just to clarify how I understand you now from what you shared above. The way you are writing to the device seems correct, U1 followed by U2 (or device B followed by device A in the context of the datasheet) I am just uncertain of what you are expecting from the return data and whether you are looking at the LSDO signal or FSDI signal.

Also make sure that the jumpers J3, J4, and J10, J11 are set to position 1-2 as this enables daisy chain without CRC.

Also you can try capture the data when using the evkit with the provided GUI to compare

To add more context, according to the timing diagram, the first byte of every LSDO should always return the DI register data (GPIO status register 0x02). For testing, I wired up the GPIO of both the MAX22190 and MAX22192. As you can see from the signal capture above, the MAX22192 is returning the exact pin status. However, on the MAX22190 side, although the input LEDs are turning on, the LSDO is returning zero. The MAX22190 doesn't respond to any commands.

Initially, I had a similar issue with the MAX22192, it was not responding to any commands but was returning the pin status. I resolved this by grounding both the GND pins on the X1 connector. Initially, I had only connected the ground to pin 5, not pin 11.

I have my suspicion of some ground breakage in the board.