If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
@JL, here is a photo, if there is not enough detail I will re-take.
[ATTACH]48467[/ATTACH]
The pic is great... everything looks good.... Lets make sure we have a problem... The waveform pic of Boost_A_G was sampled on the Gate side of the circuit, correct? The reason i ask is if it was sampled on the secondary side of the diode array it would look like this:
With a 15V 1.5 usec pusle, the max pulse current is < 100 ma in ideal conditions (charging a 3.3n)... well under the max of 300 ma for repeitive pulse current. I don't know what it is, but something is amiss in the diode array of D11, D12, D13.
@Mdtoday, are the other three drive circuits acting the same?
Yes, all doing the same JL, which leads me to think maybe BAT54S I have loaded are suspect...I purchased Nexperia and ON semi from memory so should be fine.
I'm wondering if the BAT54s I have is not capable of driving enough current to charge the 3.3nf cap?
With a 15V 1.5 usec pusle, the max pulse current is < 100 ma in ideal conditions (charging a 3.3n)... well under the max of 300 ma for repeitive pulse current. I don't know what it is, but something is amiss in the diode array of D11, D12, D13.
Yes, if somehow there is a short around the zener, the output changes to your condition. In fact if there is a short across the whole diode circuit, it will match your condition.
It all looks good JL.
I'm wondering if the BAT54s I have is not capable of driving enough current to charge the 3.3nf cap?
... I will grab a blank board an do a continuity check on it.
Yes, if somehow there is a short around the zener, the output changes to your condition. In fact if there is a short across the whole diode circuit, it will match your condition.
I did some checking also... it appears that if the zener of the driver circuit (D13 for theBoost_A_G) is reversed, it will cause this condition also.
.
In fact, it very closely follows your condition!
Wow, yes it does look very much like it... Checked the board again just now and they are mounted the right way.
Checked zener action and the markings are correct.
I will grab a blank board an do a continuity check on it.
@Mdtoday, since you have had experience in communication with the Nextion Enhanced Display, I woild like to go over my proposed approach:
(1) Since the smallest message that can be received from the Nextion is 4 bytes, set the FIFO trigger level of the 16550 Uart to 4. That way we will not be flooded with interrupts.
(2) when a recv_data nterrupt is received from the uart (4 bytes in the FIFO) issue a read_request to the Uart for 4 bytes.
(3) depending on the value of the 1st byte issue a read request for the outstanding number of bytes. There is only 1 response where the total length of the message is not known until you parse the complete message and don't think that our application will ever issue the command that will invoke that response. The response is a 0x70 "string data enclosed" which is to a respone to a get <string object >command from the mcu (after all bytes that we are concerned with are received, flush the receive FIFO (don't want extraneouse data hanging around).
After communications has established between Nextion and our embedded application, issue a "baud=<new baud rate> from the application, change the baud rate in the Uart, and issue a "get baud" (which should elicit a response) to the Nextion to verify we still have communication. From that point we are in our main loop looking for interupt flags from all connected interrupts. When a recv_data interrupt ooccurs, perform the processing listed in steps <1,2,3>, take action based on the data received. When processing interrupts for thr RX and Filters, when appro[riate do a data assignment of the appropriate varioable in the Nextion (e.g. sys0=<0xff,0xff,0xff,0xff> or a0.val=<0xff,0xff,0xff,0xff>). Most of the communication will be assignment commands of target data from our embedded application. The only messages comming from the nextion will be responses to "get commands (in the case of TX/RX parameters, and the event notifications resulting from navigation of some of the pages of the Nextion menus.
I think that is pretty much it, everything else (the RX/TX and the Nextion application) just merrily go along on their own... after initialization, all our embedded application does is play traffic cop.
... The only thing of note is the LM317 inrush current limiting circuit. I had to account for the voltage drop across the device and adjust the 5v reg output to 6.3v to get 4.5v on the output of the current limiter.
I had almost forgotten about that one.
That brings my attention to another question. Will we need another 5V regulated output to supply the Nextion power?
Checked over the whole circuit tonight, component values, solder joints, logic pulses from FPGA, all look ok.
Loaded mosfets and connected my 590uH 3 ohm test coil, still no change in pulse transformer secondary.
All 4 outputs have similar differentiation type waveform
Not sure what I have missed but will set up again tomorrow with a few more probe points soldered on for my logic analyser and DSO so I can get a better view of whats going on.
Probably something silly I've missed..maybe the toroid , just cant see what it is at the moment.
I did some checking also... it appears that if the zener of the driver circuit (D13 for theBoost_A_G) is reversed, it will cause this condition also. .
In fact, it very closely follows your condition!
Leave a comment: