Self Intermittent problem with self shutdown circuit

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

I have a strange intermittent problem with a self shutdown circuit that is not working as it is supposed to, for an AT90CAN128

The idea is the following:

-the microcontroller board will be power permanently by 12V, the uC gets 5V from a Linear Regulator that has an ENABLE signal.

This enable signal is controlled externally.

When this ENABLE signal is 12V, them the ENABLE_5V for the LTO is high and the uC will be woken up, and the uC will enable a pin that will hold this enable HIGH.

When the ENABLE signal goes from 12V to 0, the the uC is able to hold the ENABLE for the LTO high as long as it needs to do some operations, and then it can turn the pin off

and shut down it's own 5V supply.

The circuit is more complicated than this, but this is the basic operation, I also checked it in detail with  the HW guys and can't find any problem.

Unfortunately the circuit doesn't work, or it does work intermittently, like it works 1 out of 10.

From the uC side I am constantly sending high for the PIN that enable the LTO from the moment the uC is powered on, but when I turn off the 12V enable signal, most of the time

both the uC pin and the enable pin turn off and then of course the 5V drops a little later.

The delay between the 12 ENABLE going off and the uC turning it's pin off is around 1.6s, but I can't correlate it to anything in my SW.

I even tried to add some delay before the startup to see if this will change and there is no change.

I am also reading the 5V equivalent of the 12V ENABLE and outputting it's value to a LED and the uC has time to see that the 12V ENABLE is off.

Of course the HW guys blame the uC, even if I told them that I am just sending constant 5V for the enable signal and it is out of my control what is happening.

I already checked all the important signal with  the oscilloscope, indeed the hardware which is just an optocoupler, a diode and an LTO seems to work ok, but I can't find any clue to what is happening.

Any ideas of what could happen and how to debug it?

This topic has a solution.
Last Edited: Tue. Aug 20, 2019 - 08:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Last observation:

I set a breakpoint immediately after I write the enable pin for the LTO high, if I keep the uC blocked in this breakpoint then the enable pin for the LTO is alive and the circuit works ok.

So indeed the problem is in the uC.

Something happens after 1.6s and then the uC can't keep the pin high anymore ... could this be some kind of reset caused by something else.

The external 12V enable will also kill the CAN Transceiver, I had some strange problem with the Transceiver before ... I will try to disable all CAN transmission to see if the problem dissappears...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bbogdanmircea wrote:
This enable signal is controlled externally.

 

Controlled by pull/up or pull down resistor I suppose. could you please show your schematic.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think you need to make two seperate GND planes....but we cant really tell without a schematic...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will try to make a drawing of the schematic, I can't really post it here ...

Update: I tried to just set a trigger on the pin that I am constantly sending as high from the uC, and I am seeing drops of around 80ms to ground in the pin value, they seem to be quite random ... any idea what could cause this kind of behavior? Watchdog reset?

Some other kind of reset? This is really not good

I checked with  the debugger, eliminated all CAN communications and left only the pin writing, but still it is there, I will try to reduce the code to just the pin writing to see if this still happens ...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rough schematicHere is a rough schematic.

 

Attachment(s): 

Last Edited: Mon. Aug 19, 2019 - 10:30 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, after many trial and error tests I identifiend I think the culprit.

It is again the CAN transceiver!

I commented all the CAN functions and the logic works.

The CAN transceiver is also on the separation line from the 2 Ground Planes, and when the 12V ENABLE goes to 0, also the right side of the Transceiver is disabled and somehow this makes the uC get blocked

again and probably then the WDT Reset also comes around ...

How could I make sure about this?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am sorry, I cant help...what you posted above is not really a schematic...its a sketch. However, for the WDT, which MCU you are using ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AT90CAN128, Transceiver is TJA1052IT/5Y

Beware of this combination, it seems the uC goes crazy when the Transceiver has open CAN lines or right side shut down.

I am reffering of course to the CAN part of the uC, which doesn't behave as expected.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

‘Goes crazy’? In what respect? Hardly a technical description of the problem. My guess is the can interrupt gets fired and the software doesn’t manage the open bus condition correctly.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or the shutdowns not working as expected due to a port pin getting back fed power from the bus or other sneak path source.

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, the bus off is not seen correctly by the uC which keeps on trying to send in a loop. Eventually the WDT resets the uC which makes the enable pin low and then the 5V is off and goodbye!!!
I need to build a prototype to see what happens to the CAN registers when the right side of the Transceiver is off, but this will take some time.
For now I will avoid sending when the external ENABLE is off.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hardly what I’d call going crazy.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Post a true schematic to show the possible sneak paths.   Are you using the brownout detect?  Even so, if the voltage wobbles, rather than monotonically dropping (goes down,down, up, down), things can get wacky.  Why might it go up?    Some parts may quit drawing current below some value, the removal of their loading lets the voltage suddenly rise slightly (perhaps due to some cap storage) as it continues to drop overall.  Once the software decides to shutoff, it should ignore any condition that might tell it to restart any power supply control pin.

 

The delay between the 12 ENABLE going off and the uC turning it's pin off is around 1.6s, but I can't correlate it to anything in my SW.

how can that be?  You monitor the pin & decide to do a shutdown, right?  Once you decide, allow nothing to override or restart the pin.  What part of your code turns ON  the supply?

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's also those Schottky diodes - these babies like to leak with temperature if you're not careful with your design.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The hardware part is working ok, I didn't test in in extreme conditions.

The 5V supply has no fluctuations, as long as the Enable signal for it is ok.

Like I said, disabling the CAN send functions when the Transceiver is off solved the problem, the driver function for sending a message has a while loop waiting for a confirmation that either the message was sent correctly or

some busoff or another type of error happened.

I already corrected this functions once when it was hanging when I was disconnecting the CAN connection, but even with this correction it is still hanging now when the right 5V side of the Transceiver is disabled.

It would be really helpfull if anybody with more knowledge about the CAN HW can read the datasheet for the Transceiver, there are some mentions about the left and right side 5V supplies of the Transceiver going off, this is an Isolation Transceiver

for high voltages, but it seems that it is having some problems on my board even if the circuit is made exactly as in the datasheet.

I will push for a redesign of the board with  another Transceiver, it seems this one has too many problems that take a lot of time to solve, and fixing by SW possible hardware problems is not a good way.

 

Last Edited: Tue. Aug 20, 2019 - 08:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Like I said, disabling the CAN send functions when the Transceiver is off solved the problem, the driver function for sending a message has a while loop waiting for a confirmation that either the message was sent correctly or

some busoff or another type of error happened.

Sounds like perhaps a software issue, not accounting for some possible system states? 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!