Announcements

From sunburn to sun earn – we’ve got the power! Watch our #poweringgreen videos now.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
AhmedSaber
Level 2
Level 2
First like received First solution authored 10 replies posted

Hello,

I'm using the target AURIX TC387, connected to the TLF35584 "variant: TLF35584QVVS1 ". and enabling the TLF FWD, which is being triggered cyclically from the MCU.

Now, I need to set MCU into the halt mode, and for the sake of more power reduction, I need to set the TLF into Sleep mode as well, I'm setting the TLF into the different states via SPI commands.

If I set the TLF and the MCU in the sleep mode, I got an external reset from the TLF FWD, While as per the UM of the TLF, it says the TLF itself will take care of disabling the FWD with the transition from Normal to Sleep mode
Section 11.3.3, pages 100,101

Even If I tried to disable the TLF FWD manually via SPI command before sending the TLF into sleep mode, still got this External Reset.

Am I misunderstanding the manual?/What is the correct sequence to handle such situation between the MCU and the TLF

 

 

0 Likes
1 Solution
µC_Wrangler
Employee
Employee
50 solutions authored 100 sign-ins 25 likes received

Nothing reveals Truth like a scope, but here are a couple ideas to try:

#1: Are you using the iLLD, the MCAL, or your own code to send SPI messages?  Could it be that after you send the final Go to Sleep that the last byte of the SPI message isn't going out?  For example, the MCAL relies on interrupts... so if your code calls Spi_AsyncTransmit, then disables interrupts before the callback completes, the last byte will never be sent.

#2: Are you seeing any voltage dip at all on VEXT, or is the TLF35584 returning to wake immediately?

#3: Just to verify the SPI baud rates, system clocks, etc., can you verify that the FWD watchdog triggers if your application services it, say, every 12 ms instead of the regular period?

View solution in original post

0 Likes
5 Replies
µC_Wrangler
Employee
Employee
50 solutions authored 100 sign-ins 25 likes received

Hi Ahmed.  Are you sure you're not tripping over this erratum?

PMS_TC.005 Voltage rise at P33 and P34 up to VEVRSB during start-up and up to VLVDRSTSB during power-down

It's sometimes the case that as VEXT is falling as the TLF35584 enters sleep mode, the AURIX P33/P34 pullups get activated, and that in turn can lead to waking the TLF35584 back up.

Otherwise, have you ruled out trouble with WWD?

0 Likes
AhmedSaber
Level 2
Level 2
First like received First solution authored 10 replies posted

Hi Wrangler,

Thanks for your fast response,

I can't figure out why this erratum can be correlated to the TLF wakeup, because this AURIX P33/P34 are not connected anyway to the TLF.

What I can guarantee because I have tried it, as follows:

If I started the MCU alongside the TLF, while disabling the TLF FWD at the TLF INIT state then move the TLF to normal. hence the MCU is not being requested to service the FWD.
And later setting the MCU and TLF into sleep mode, works fine without any interrupt.

From this trial, I can assume that the problem definitely comes from the wrong handling to disable the TLF FWD.

What do you think?

0 Likes
µC_Wrangler
Employee
Employee
50 solutions authored 100 sign-ins 25 likes received

Glad P33/P34 aren't involved - that's the most common source of trouble.

Good experiment with disabling the FWD.

Can you provide a log of the SPI traffic?  Timing might help if you can manage to capture that too.

0 Likes
AhmedSaber
Level 2
Level 2
First like received First solution authored 10 replies posted

Hi,

 

Unfortunately, I don't have the capability to capture the SPI traffic.

As I understand from the TLF UM, Normal to Sleep transition subsection
" Before the SPI command “Go to SLEEP” is applied, the watchdog(s) - if in use should be serviced, so that the
positive edge of SCS signal is well in between the “closed window” of the window watchdog. This is
recommended to avoid interference between a missing watchdog trigger and the transition command “Go to
SLEEP
"

AhmedSaber_0-1662578284318.png

So What I have tried is:
Service the FWD immediately before disabling it via SPI command
Considering the FWD trigger cycle time is configured to 11ms, which I think so enough to transit from Normal to Sleep safe, I assume the Ttr,del would not reach this 11ms any way.

 

0 Likes
µC_Wrangler
Employee
Employee
50 solutions authored 100 sign-ins 25 likes received

Nothing reveals Truth like a scope, but here are a couple ideas to try:

#1: Are you using the iLLD, the MCAL, or your own code to send SPI messages?  Could it be that after you send the final Go to Sleep that the last byte of the SPI message isn't going out?  For example, the MCAL relies on interrupts... so if your code calls Spi_AsyncTransmit, then disables interrupts before the callback completes, the last byte will never be sent.

#2: Are you seeing any voltage dip at all on VEXT, or is the TLF35584 returning to wake immediately?

#3: Just to verify the SPI baud rates, system clocks, etc., can you verify that the FWD watchdog triggers if your application services it, say, every 12 ms instead of the regular period?

0 Likes