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.

Hi David,

Are you able to solve this issue or it is still opened? Please let me know.

Regards,

Yuriy

Dear Yuriyk1,

I received the MAX14912 EVK. I positivly checked all behaviours I would replicated on my board. But the behaviour I detect on my board is not feasible on the EVKIT.

Since I am not able to explain myself the behaviour on my board (since there are not any short circuit in the board when the card was turned off), I need to investigate what the MAX14912 registers contain in the devices on my board. To do this, I need to replicate the command mode protocol when SRIAL=0,PP=1,EN=1, following table 8 of page 26 of the datasheet.

Please note the right protocol used from Analog Devices to investigate the device is not really explained.

I was forced to obtain the correct log investigation protocol by extrapolation from your software (log window). I don't think the correct investigation procedure is written anywhere. Especially the need to repeat the request to get the logs information on the second request of the same type.

Apart from this, unfortunately I have to recognize that if I query EVKIT from USB the register 5 always shows the result 0xA4, while if I query it from "external SPI" (made with another custom circuit), the result is 0x24. It seems that the watch-dog does not create problems in the second case....

One more doubt about the possible mismatch description used in your software (EVKIT v1.11) and table 9 (FAULT SUMMARY) on page 31 of the datasheet.

If I'm not mistaken, in Analog Device's software (EVKIT v1.11) the register #7 is referred to TABLE 7 on page 29 of the datasheet, too. In this case the description refers that any bit of register 7 emphatizes an OUT-overvoltage-detection. In table 9 at page 31, the last row is named "Short circuit". I think it would explain that if there is at least one OUT channel with a short circuit, the FAULT* pin goes low, BUT -at the same time- it refers to REG7.

What does this mean? 

If a short circuit has detected on OUTx, the pin FAULT* goes low ....AND do the x-bit of the REG7 goes high, too? (So, It seems any bit of register number 7 carry both informations about overvoltage output AND overcurrent output. Is it correct, please?)

Thank you very much for your availability.

Best Regards, Davide.

As conclusion of my investigation about MAX14912, I finish to check the SPI state on my board in the following condition (how I already written): SRIAL=0; PP=1; EN=1; IN1=...=IN8= 0; BUKEN=0; V5=5V external and 3V3 external.

At startup, I detected the default value (0x00) on registers 1,2,3,4,5,7. The register 6 is equal to 0x07, while its value detected over MAX14912EVK on USB was 0xA4 and the same register (always on EVKIT, too) is 0x24 if checked by external SPI (different from Analog Devices test program). These behaviours I think were compatible with the different bias conditions.

On my board, if I force any input to "1" , the associated output goes to "1" with a duty about 30%, but while the FAULT* pin is always "1" (as is the internal output mos does not turned on), the MAX14912 internal register may emphatize the fault condition answering to 0x30+0x00 command, with a values "1" on correponding bits.

For example, if IN1=1; IN2=...IN8=0; writing on SPI the "Read-Real-Time Status" command , the MAX14912 answers 0x10 sometimes (as is when the physical output goes "0" instead the correct "1" value.......I suppose). Since the real-time status is not always "1", it is possible to read a "0x00" value in the same condition. This is acceptable as written in the datasheet. Despite this correct/acceptable behaviour, I expected that the global FAULT* signal would also go to "0" for the times foreseen by the datasheet.

I apreciate your answer.

Regards, Davide.

Davide,

After power up the board, try to read register 6 two times sending command 0xA0+0x06. All IN_ pins should be 0. After second SPI transaction you should get 0x0000.
Command 0xA0 is a read command 0x20 with Z MSB=1.  MSB=1 clears all fault conditions from the previous operation. If you don't get 0x0000 after second SPI transaction, then something wrong with your setup. If register 6 still equal to 0x07 this means that the respecting V5 and VDD are below undervoltage thresholds. Double check the power on your board.
Let me know if you can successfully pass this step. Then we can try the next step.

Regards, Yuriy

Dear YuriyK1,

Sorry, I forgotten to write back to you. I am perfectly able to reset Register 6. After the reset (0xA6+0x20), the 6th register is resetted to default value 0x00 (as is, no condition of error are present).

Regards, Davide.

Ok, when you are able to read 0x00 from register 6 try to set one of the IN_ pin, for example IN1, to high. Does the OUT1 become 24V? If you still see the 30% oscillation, what you read from register 6?

Regards, Yuriy

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

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