TCAN2451-Q1: Sleep mode strategy in TCAN2451

Hi Nishant,

I apologize for the delay - I have been out of office. 

This device really isn't good for 96V systems - it is a 12V device that can accept up to 28V on its supply pin. If you still can find a need in your system for that please see below. 

If you haven't requested a datasheet please request one on TI.com and there if you have an FAE that you can talk to you will have an even better chance of being approved for the datasheet as most of this information is in there. 

1. VCC1 and VCC2 are off by default in sleep mode and the WAKE pins can be used. By default they are all on and will accept either a high to low or low to high transition by default as a wake signal. There are a lot of configuration options - but you can pull up the WAKE pin to VSUP voltage and have a switch that when pressed goes to ground which would be enough to trigger the wake up signal. From wake the device transitions back to standby. 

2. The SBC can be woken up by a CAN BWRR (bus wake receive request) when in sleep mode with VCC1/VCC2 off (low power CAN receiver is powered through VSUP). When the wake up pattern is received the SBC will transition to standby mode and flag the processor through the CRXD pin - by default it latches low and can be configured to toggle. The controller can then take control and push the SBC into normal mode at which point the CAN transceiver can be turned on. CRXD is referenced to VCC1 - CRXD will not alert controller of bus wake until SBC has entered standby mode and VCC1 has turned back on. nINT pin isn't really going to be used for WAKE (it will alert the processor, if connected,, that an interrupt has occurred and a wake event is an interrupt) 

3.Yes it can work without VCC1 and VCC2 in sleep mode - the CAN transceiver just needs to be set to wake capable before sleep (which it should be by default). 

4. TCAN2451 supports classic CAN protocol - but the physical layer is CAN-SIC - which just means the recessive bit edge is driven - from a protocol level it is compatible. TCAN2411 is non-SIC version. 

5.After wake up the device transitions to restart mode, in restart mode VCC1 and VCC2 start ramping, when VCC1 has been stable and at proper level for long enough time (configurable) the device transitions to standby mode and indicates on CRXD of the wake up even. 

6. The HSS pins are just switch outputs - if the external circuit is within voltage ratings and the current is <=100mA it should be okay to use. By default they are off. 

7. VCC1 is off in sleep mode by default- it turns on automatically when device restarts - VCC1 needs to be on for normal device operation. 

Like I said at the start - this is really a part for 12V battery systems - I have seen 96V systems utilize a 12V battery somewhere and if that is what you are doing then this device could work - but it won't be able to run directly off the 96V or anywhere close to that. 

Please let me know if you have any further questions!

Best,

Parker Dodson 

Hi Nishant,

Okay - thanks for the confirmation on the 12V aux battery - that is fine. 

So for the wake up - the nINT pin doesn't become active until the device enters standby mode, the nINT pin will signal to processor that there is an interrupt due to the wake up after the device enters standby mode - but for the time period between wake up signal received and the device transitioning from sleep to standby through the restart mode there will be no indication of the SBC being woken up. Every wake condition has its own interrupt - CAN bus wakes will also signal through CRXD pin when SBC enters standby mode (latch low by default, but can be set to toggle). 

So any wake will be indicated by nINT pin - but VCC1 needs to be active for nINT to be active which will be in standby mode (sleep mode -> wake up -> restart mode (VCC1 ramping up) -> standby mode (VCC1 is on and stable). CAN bus wakes will also be indicated on CRXD pin. 

Please let me know if you have any other questions and I will see what I can do!

Best,

Parker Dodson

Hi Nishant,

By default the GFO pin is a general purpose output - its state is controlled through SPI commands. The number one use of this pin was intended to be used to control (inhibit/enable) external CAN transceivers - so you should be 100% okay to use the GFO pin in that way. 

There are some alt functions - but you have to program them - they essentially allow the GFO pin to trigger on specific interrupts such as with VCC1/VCC2 or watchdog - but by default it is a general logic output. 

Best,

Parker Dodson

Hi Nishant,

You are correct - the only thing I would add is the CRXD pin will also reflect a wake up when it transitions to standby(either by latching low or toggling depending on configuration).

The interrupt registers will give you more information as to what caused the wake up condition (so you can differentiate between a LWU or a CAN wake) - interrupt register 1 (address 0x51) has bit 6 as the CANINT1 (which will trigger due to a CAN wake up) and bit 5 is the LWU (which will trigger if wake source is one of the WAKE1, WAKE2, or WAKE3 pins). 

So by reading address 0x51 you should be able to determine cause of wake up. 

Please let me know if you have any other questions!

Best,

Parker Dodson

Hi Nishant,

There are a few factors to consider as we don't have a single specification to define that. 

For the case of a local wake up (LWU) through the WAKE pins it depends if they are set to pulse detection or edge detection (by default they are bi-directional edge detection). 

For edge detection the wake stimulus must be held for >= t_wake which is 140us - however you may get detection after only 10us - but you should plan for 140us at minimum. 

After the wake signal has been detect the device immediately transitions to restart mode and starts ramping  up the VCC1 and VCC2 voltages. For the device to enter standby mode after exiting sleep VCC1 >= UVCC1R for tRSTN_act which is between 1.5ms and 2.5ms with a typical value of 2ms. 

UVCC1R is configurable and there are 8 potential options depending on software configuration and how VSEL pin is connected. But for sake of example let's assume 3.3V VCC1 output and default configuration - that would put UVCC1R between 3V and 3.2V with a typical of 3.1V - so VCC1 needs be over 3.2V (worst case scenario) for up to 2.5ms before transition. 

VCC1 does have a soft start timer and from 0% to 90% of selected VCC1 value (either 3.3V or 5V) will be typically 1.8ms. So roughly you are looking at 1.8ms + 2ms + 140us (typically) to get from wake up event to standby mode (3.94ms) at which point CRXD directly responds. But if you use a lower recovery threshold (the default is the highest recovery threshold) you could see it be slightly quicker - it will need to be tested in your own system to verify - but it should be pretty close to what I describe here. 

If you are using pulse detection on the WAKE pins - the timing will increase. By default (i.e. the only thing you change after you change wake pins to pulse detection) if you are using pulse detection the pulse must be at least 10ms but can last up to 750ms. But it can be increased as far as a minimum of 80ms with a max 2000ms depending on configuration. So it will be the same calculation as above but replace the 140us with at least 10ms - so 13.8ms total estimated time (assuming same configuration as previous example) compared to 3.94ms as the last estimated time - but that 13.8ms could increase to roughly 2 seconds depending on exact scenario and configuration. 

If you are looking at the a CAN BWRR using a wake up pattern - which is defined as a filtered dominant, filtered recessive, and a second filtered dominant pulse with each pulse being  at least tWK_FILTER which is between 500ns and 950ns - so with 3 back to back (assuming no other bus traffic in-between filtered pulses) would be 1.5us to 2.85us  - at the completion of the final dominant the device will then go through the same procedure as the above examples. Which would get you typically a value of 3.8015ms to 3.80285ms - so roughly 3.8ms. However - this assumes that the bus wake up pattern is happening back to back - which may not be the case - there is a time out period of up 800us to 2ms - so longest possible time is 2ms for the wake up pattern to occur which would put the time delay of about 5.8ms.

The times will vary though based on multiple factors including configurations of the VCC1 recovery thresholds and other SBC configurations. However you are still looking at a few ms at the quickest - this includes the wake detection - but that is such a small part of the delay generally speaking (unless using pulse detection) that if you exclude it the overall delay doesn't change that much. 

Please let me know if you have any other questions!

Best,

Parker Dodson

Hi Nishant,

For questions 1/2/3 please see below:

LIMP pin needs to be pulled up to VSUP (so 12V) because you need to have LIMP pulled high when in sleep mode if there is no issue. LIMP pin is specifically for LIMP home mode in the vehicle.

"
Limp home mode, is a safety feature in vehicles that activates when a serious issue is detected by the engine or transmission control unit. It limits the vehicle's performance, such as reducing engine power and speed, and sometimes disabling non-essential features like air conditioning, to prevent further damage and allow the driver to safely reach a repair shop or their destination

"

The LIMP pin will pull low during watchdog failures (could indicate communication between MCU and SBC is bad which could pose serious risk to system) and beyond the watchdog failures it will indicate when the SBC is in fail-safe mode. During fail-safe mode VCC1/VCC2/VEXCC are all disabled - you may say to yourself - "well that is okay - because it should go low during fail-safe mode" - but the issue is that during sleep mode VCC1/VCC2 are off and if you pull up to VCC1 the LIMP pin would be floating/low which could be pushed downstream causing the vehicle to go into LIMP mode which basically makes the car undrivable due to major error - but the thing is there would be no error since the SBC is just asleep. LIMP home systems utilize battery voltage to signal - not the MCU signals - in a lot of cases the MCU will also be unpowered during fail-safe (most SBC applications will have SBC power the MCU - so SBC is not providing power the MCU will be off). 

Not every application is going to utilize the LIMP pin - and you can leave it floating if unused - but for systems that do it needs to be pulled up to VSUP to properly indicate when the SBC is in a fail state. 

4. Connect unused wake pins to GND (direct connection - no pull-down needed)

5. The nRST pin is an input most of the time - it only acts as an output when the SBC is in restart mode. Typically it is a direct connection from nRST on the SBC to the restart pin of the MCU - nRST is pulled up to VCC1 through a 30k pull-up internally so you don't need to add anything externally (but you can - some people do - it isn't a huge issue to do that). The nRST outputs a low when the SBC enters restart - by default every missed watchdog results in an SBC restart (you can increase the amount of times watchdog can fail before restart - but by default it is one) - that will cause SBC to go to restart mode and also pull nRST down - which in turn should reset the MCU. If the SBC is in normal or standby mode the MCU can output a low signal to the nRST pin to cause the SBC to go to restart mode - but it does require the MCU's reset pin to be bi-directional.  It should be noted - that any event that causes SBC restart will cause MCU to restart including things like UV events on VCC1. 

Please let me know if you have any further questions and I will see what I can do!

Best,

Parker Dodson

Hi Nishant,

For your overall process there is one detail that is incorrect - the VCC1 supply will start ramping in Restart mode - when the VCC1 has ramped up and is stable the SBC will then transition to standby mode. Both VCC1 and VCC2 will ramp up in restart mode - but only VCC1 is required to be up and stable to enter into standby mode. Beyond that it looks okay. 

You can use Wake pins during normal operation - they will generate interrupts - but that is basically all they will do when in standby and normal modes. So they can be used to indicate to the MCU that they have detected a wake signal but they won't really change how the SBC is acting if using standard wake on these pins. Essentially they work as programmed in standby and normal mode. 

Yes watchdog is SPI based. You write the watchdog trigger (according to device configuration) into register address 0x15. The main purpose is to ensure SPI communication is working properly. 

Please let me know if you have any other questions!

Best,

Parker Dodson

Hi Nishant,

As long as the requests are essentially edge based (i.e. high to low or low to high transition -this the default setup of the wake pin) that should be okay. The WAKE pins don't really read any information - it is a flag so yes/no kind of answers. You can also set it up to read a pulse - but that pulse length will need to be in ms range to be read and it will require you to configure it. 

But yes - if the smoke sensor sends requests that meet the detection criteria of the WAKE pin as you have configured them - a flag will be generated in any mode where WAKE is active (which should basically be any mode but restart mode). 

Best,

Parker Dodson