MC33908 FS0_b behaviour

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MC33908 FS0_b behaviour

Jump to solution
5,405 Views
aero72
Contributor III

Hello,

I'm asking a question about the MC33908 SBC in companion to a MPC5744P. We've noticed some strange behaviour on the FS0 output during a requested reset of the processor.

The attached trace shows !RST in yellow and !FS0 in green. The falling edge of !RST is caused by a request from the microprocessor over SPI to the SBC to have its reset line asserted. This will cause the fail-safe state machine go back to its init state, and cause FS0 to become asserted.

As you can see, !RST is released after 16ms - but look at the voltage level of FS0 - it certainly isn't a convincing digital

state.

After !RST is de-asserted, software starts again going through the complete initialisation of the SBC again, including the fail-safe state machine, watchdog, and zeroing of the reset error counter.

After all that is done, software attempts to have FS0 de-asserted. I assume this happens more or less at the time where there is a step in the green trace - 10ms after software start would be about right.

As you can see, FS0 is not at a valid voltage level thereafter - not surprisingly, connected fail-safe outputs are inhibited.

The circuit on the FS0 pin is pretty much as recommended; a 10nF capacitor to ground, 5k6 pull-up to 3V3, 5k6 in series to the rest of the world - which in this case is all CMOS logic devices (3 off).

 

Interrogation over SPI of the WD_ANSWER register shows that it thinks FS0 is de-asserted and everything is perfectly fine.

 

Has anyone else seen the FS0 do that?

 

Thanks in advance for any suggestions.

Labels (1)
0 Kudos
Reply
1 Solution
5,131 Views
aero72
Contributor III

Tomas,

Looks like the issue is with external circuitry. 'FS0'_SBC_OUT works OK when I remove R42...I took a look at a logic gate attached to 'FS0'_SBC which did not look like it had reflowed properly. After re-wetting the pins, the logic level on that net now looks good. I think that gate was missing its supply or ground connections.

Thanks for your thoughts in looking at the issue.

View solution in original post

0 Kudos
Reply
6 Replies
5,132 Views
aero72
Contributor III

Tomas,

Looks like the issue is with external circuitry. 'FS0'_SBC_OUT works OK when I remove R42...I took a look at a logic gate attached to 'FS0'_SBC which did not look like it had reflowed properly. After re-wetting the pins, the logic level on that net now looks good. I think that gate was missing its supply or ground connections.

Thanks for your thoughts in looking at the issue.

0 Kudos
Reply
5,131 Views
aero72
Contributor III

Tomas,

Thanks for your response. Attachment shows where/how processor lines are attached to SBC. The net called VDDL is the VCORE output from the SBC and is 3.3V. This is also the net connected to the VDDIO pin of the SBC. VCCA = 5V (with internal transistor). VAUX is set up as a tracking regulator with an external PNP. All of that is working fine.

For completeness, I have also patched in how the !FS0 line is used downstream of the series 5.6k; you can see it connects to CMOS AND gates as a combinatorial function with a microprocessor output pin.

I note compared with Figure 58 of the latest MC33908 datasheet that my schematic uses 10nF tank capacitors on !NMI and !RESET (pins 29 and 24), the datasheet suggests 1nF. This may account for the slower release of reset than you were expecting, but I would hope that shouldn't affect the behaviour of the fail-safe state machine.

I'll get you a trace as requested; any thoughts my use of 10nF might cause a problem?

Regards,

0 Kudos
Reply
5,131 Views
aero72
Contributor III

...and here's the trace you wanted.

Yellow = reset; Green = VDDIO; Purple = VPRE; Pink = VSUP3

So reset pulse is 16ms as before, but no sign of dip or glitch on any of the other 3.

Regards,

0 Kudos
Reply
5,131 Views
TomasVaverka
NXP TechSupport
NXP TechSupport

Hello Andrew,

It seems that the RSTB duration is maybe extended by the MCU itself. Anyway, this is not a problem and this is not explaining FS0B behavior.

 

From your schematic extract I understand that FS0B_SBC_OUT is the SBC device pin. Can you please desolder R42 in order to isolate FS0B and verify if the behavior becomes OK nor not?

- If yes, then it is an external issue.

- If no, then there is a link with the SBC, but so far I cannot explain it.

schematico.jpg

It looks like when FS0B is asserted low, there is a voltage divider not allowing FS0B low level, but forcing intermediate value…

Regards,

Tomas

0 Kudos
Reply
5,131 Views
aero72
Contributor III

Tomas,

I've been away for the last few days.....but will get back on this shortly....to keep the project running before I left, I de-soldered R42 myself and tied the line high...I will get the board and take a look at the SBC side of the joint to see if it is still floating.

Regards,

Andrew

0 Kudos
Reply
5,131 Views
TomasVaverka
NXP TechSupport
NXP TechSupport

Hello Andrew,

RSTB request by SPI would assert the RSTB line for 10ms, not 16ms. 16ms corresponds to the time to release RSTB from POR or after wake up from LPOFF, unless the MCU maintain the reset line over the SBC. So looks to me that something else happens.

 

Could you please provide:

 

- The schematic around MC33908 for review?

- A scope plot with Vsup3, Vpre, VDDIO and RSTB to understand what happens?

Best regards,

Tomas

0 Kudos
Reply