all MAX14912 outputs in push-pull and parallel mode switch @duty=30% while INPUT is always high.

Hi Davide,

This behavior is unusual. Could you please specify what you are using to create a 3.3mA load current, and what the current of the 24V supply is? Also, is the 24V supply stable?

Hi YuriyK1,

Thank you very much for your kindly reply.

My circuit is composed by 2 indipendent MAX14912 devices. They work both in push-pull and parallel mode, too.

The 24V is always stable becuse the load is almost negligable.

The supply circuit is made to bear 250mA x 16 outputs = 4A.  Please note that the 16 loads combined with the outputs (one for each output) are made up of a series of a LED and a 6.8Kohm resistor. They serve only to verify the physical value (0V...24V) of each output.

I think something intervenes, like a watch-dog or another protection that I inadvertently triggered through the circuit I made. The 30% percentage is really "strange".

Please note nor UVLO* and FAULT* open collector outputs intervenue.

Regards, Davide.

Dear YuriyK1,

After boot and reset I read on register 6 the "0x00" value. This is the right condition to start the test. Please note, after reset, all registers are "0x00". (Since register 6 before reset was "0x40", I am sure to communicate in the right way with the device).

After this, I put IN1=1 and the OUT1 oscillates with 30% of duty, as usual in my experience. Please note I could put to "1" any INput and I will gotten the corrispondent OUTput pin with 30% of duty.

The register 6 (investigated with 0x20+0x00 bytes) shows the value "0x00" when read, as if no error were present. Please note I investigate about any 1000 milliseconds cycle. Again, all registers have the default value (after reset) of "0x00".

***********

Please note, it was only with Real-time-status command I could read the fail(s) ("1" bit value) on channel(s) as I aspected. This correct "fail flag" was not always asserted. I think it happened when the MAX14912 detected the difference between the output at 0 voltage while the input was at logic one, as is the about 66% of the duty cycle .

************

Regards, Davide.

Hi Davide,

To read register 6 you should send command 0x2006 (two bytes while CS=0, where the first byte is read command 0x20 and the second byte is register address 0x06). When you send 0x20+0x00 you read from register 0.
Please refer to the Table 8 of the datasheet.
Could you please repeat that sequence again with the correct command?

Regards, Yuriy

Hi YuriyK1,

Sorry, I wrote in a bad manner the SPI request used. I follow the EVKIT protocol: writing 0x20+0x06 (discharging the MAX's answer) and writing again 0x20+0x00 (considering the second MAX14912's answer, as the response to the first "0x20+0x06" to read register 6). In example, the log below:

So, I did the right requests, but foolishly I omitted to write back you correctly.

Regards, Davide.

Hi Davide,

It is not clear when you get "0x00; 0xa4" after reading reg. 0x00 or reg. 0x06. When you send 4 bytes you should receive 4 bytes.
0xa4 is a register value from previous command, refer to Table 4 of the datasheet.
Could you modify your program to issue the following command
SDI: (CS=low) 0xA0; 0x06 (CS=high); (CS=low) 0x20; 0x06 (CS=high)
SDO:      0x??; 0x??            0x??; 0x??

Thanks, Yuriy

Dear YuriyK1,

I copied the same wording used by Analog Devices software "MAX1491x software version 1.11".What I posted is the screen of your software on the log window (completed with the values ​​of some setting pins). However, I modified the software as you asked me, trying to be as comprehensive as possible. I hope I succeeded. 

The sequence is the following.

[TURN ON the voltage on the board: all INx pins are "0"; SRIAL=0;PP=EN=1; all OUTx = 0; CS=1]

I Send to MAX14912 the following requests:        [CS=0] 0x20,0x06 [CS=1] ... [CS=0] 0xA0,0x06 [CS=1] ... [CS=0] 0x20,0x06 [CS=1] .

The device answers me with the following bytes: 0x00, 0x07                        ... 0x00, 0x00                         ... 0x00, 0x00 .

[for example, TURN ON IN1, as is IN1=1, and the OUT1 oscillates with 30% of duty].

Again,I Send to MAX14912 the following requests: [CS=0] 0x20,0x06 [CS=1] ... [CS=0] 0x20,0x06 [CS=1] ... [CS=0] 0x20,0x06 [CS=1] .

The device answers me with the following bytes:    0x00, 0x00                        ... 0x00, 0x00                         ... 0x00, 0x00 .

The result is the following. Even if I was sure to be able to read register 6, (infact, after power up the board I read some NORMAL warnings on register 6),  after the reset, always I read 0x00 on register 6.

In other words: after the reset the value of register 6 is always "0x00" whether one or more outputs (OUTx) are at level 0 (due to INx=0), or whether they produce oscillation with a 30% duty cycle approximately (due to INx=1). Thus, faults on register 6 never detect any error conditions.

I hope to be clearer then the last time.

Regards, Davide.

Hi Davide,

Based on these experiments we can conclude the following.
1. 30% duty cycle oscillations on outputs is seen on your application board.
2. The MAX14912 does not report any fault conditions during oscillations.
3. You cannot replicate these conditions on the MAX14912 EV kit with similar setup.

Based on the above I would conclude that issue is related to your application board or/and setup.
I would suggest to try
1. Remove the MAX14912 from your application board and wire the OUTs from EV kit to the respective points on your board.
Check
a) does the same oscillation is still seen when you control the MAX14912 by EV kit GUI?
If yes, then the issue is related to the external components on your board.
If you don't see oscillation, then the issue is related to controlling software/hardware or board layout.
b) do you see the same behavior if you control the MAX14912 EV kit using your application board software?

Regards, Yuriy

Dear YuriyK1,

What you ask me is unfeasible. I will rebuild the card, but that device is not a simple THT resistor! And in any case I will not compromize the behaviour of the  MAX14912 EV kit. It is not simple nor quick to got .

The last question(s).

Please, look back to my (initial) schematic I posted.

1) Is it possible that the MAX14912 mounted on  MAX14912EVkit has a different behaviour from a general MAX14912 device bought by Mouser (or other vendors) and set by our schematic showed in the post dated "Jun 6, 2024", please?

2) The MAX14912 appears to be a device that also has a finite state machine. Is it possible that in the EVKit circuit, the FT CHIP IC sets the state of this finite state machine when turned on in a way that is clearly not replicable with our scheme? (In particular, is it necessary to carry out some sort of serial SPI programming BEFORE being able to work in parallel with the MAX14912?)

Thank you very much.

Regards, Davide.

Hi Davide,

1) It is absolutely impossible that the MAX14912 behave different on EV kit and as a general standalone device. This part is on market for years and we don't see such behavior. Any behavior discrepancy always validates on the EV kit first and then goes to design simulation and verification. We strongly believe if the issue cannot be replicated on EV kit, then it is not related to the part.
2) You can double check on the MAX14912 EV kit that the device does not change its state under normal operation conditions. On the EV kit you don't need to use USB and the GUI at all but control the outputs via respective IN_ pins and EN, SRIAL, and PUSHPL pin settings.

If it is hard to substitute the MAX14912 on your board by connecting EV kit, then I would recommend replicating your conditions by adding the external components (like pull up/pull down diodes etc.) to the EV kit. We need to understand what causing such abnormal behavior on your board.

Regards, Yuriy

Hi Yuriy,

We replanned the board using different constraints.

With the new spacing rules we set, modifying the component pads with respect to the basic values ​​you provided, we succeeded in making it work.
...I still don't understand what happened on the old boards because there is no conductivity between the pads when turned off, while it seems that the insulation gives way at 24V.
That's it.
Greetings, DB.

Hi Davide,

I am glad that you can make it work.
I think the problem was related to the external protection diodes. The high dV/dt can turn on external protection that cannot trigger the internal diagnostic. When you increase the spacing between components the dV/dt from adjacent lines becomes weak. In any case it's all behind.
Regards 

Hi Davide,

I am glad that you can make it work.
I think the problem was related to the external protection diodes. The high dV/dt can turn on external protection that cannot trigger the internal diagnostic. When you increase the spacing between components the dV/dt from adjacent lines becomes weak. In any case it's all behind.
Regards