watchdog to reset the processor under fault situations

Hello Ahmed,

First thing is to find out why it does not hibernate. If that is because of some status that the uC is waiting for?

Regards
Amit

Hi Amit,

I am being searching for this for a long while but in vain ! Everything looks good and I have added your suggestion for clearing the FIFO from junk data that may stuck the program. This condition rarely happens (it can happen after 2-3 weeks of working) that makes us believe the code is working good. Also, the rare repetition of the problem makes it very hard to troubleshoot it. We have noticed that high static energy from winter coats may affect the uC and makes it behaves strangely and wakes up/can not hibernate.

We will place the uC with the RF circuit at a remote area and we need to be sure that if any unexpected condition happens it will not stuck at wake up status to discharge the battery. For this reason I am searching for the safest condition to reset the processor if that happens.

Regards
Ahmed

Hello Ahmed,

Let us simplify the problem

1. Yes. You can add a watchdog timer at the beginning of every boot up after hibernate. If the device does go into hibernate the watchdog will be disabled as the Vcore is 0V in hibernate. If it does not then in the WatchDog Interrupt handler, put a while(1) loop to cause it not to service the interrupt handler as it will not clear the interrupt status and then cause a reset. On the next boot after the reset ensure that you check for Watchdog as a cause of reset and log it.

2. It would be worth investigating it under lab condition. Since you menationed high static energy and the fact that the device is being used in VDD3ON for hibernate, you may want to look at the errata where GPIO's can latch up in TM4C123 causing the current drain,

Regards
Amit

Hi Amit,

For number 2, today I have noticed that when I disconnected the multimeter that measures the battery voltage, the uC stuck when it wakes up from hibernate ! I know that any connect/disconnect for any peripheral on the GPIO can cause problems for the uC. But why connect/disconnect a multimeter on the battery can cause this ? Do you think that the uC is very sensitive during hibernation mode to any change in voltage or peripherals ? It is not the first time to recognize this, a lot of motion around the uC or moving it from place to another may cause the same behaviour ! I have to push the reset button to enable it again.

For this reason I would prefer to use a code to restart it in such situation. Does using the watchdog timer for code restarting give the same action as pressing the restart button on the Tiva C launchpad ?

One more thing, how can I get 5 sec watchdog timer ? I followed your code lines for a previous answer and I found:

WatchdogReloadSet(WATCHDOG0_BASE,SysCtlClockGet()); //1 sec watchdog timer

Regards,

Ahmed

Hello Ahmed,

The Hibernate is sensitive to VBAT level changes. If the VBAT falls too much, the Hibernate will be reset causing the uC to be woken up. However if the hibernate is reset it will be treated as a power on.

As for the Watchdog if you multiply the vale from SysCtlClockGet by 5, it would amount to 5 seconds.

Regards
Amit

Hello Amit,

Today again I found that the uC wakes up and worked successive times (around 7 times) in less than a minute-while it has to wake up every hour from hibernate-and then stopped and drained 25mA continuously till I reset it ! From previous lab measurement I know that the 25mA means that the core is working alone without any GPIO or peripherals. That means that the program can not hibernate for 7 times (because the RF circuit transmits the data 7 times) and then the peripherals have stopped while the core is still draining. I am covering it with antistatic bag and never touched it.

Note that I am connecting a Fluke multimeter in series just after the battery to measure the drained current. I am saying this because when I was connecting another cheap brand multimeter it sometimes stuck the uC and prevents it to hibernate. Do you think this multimeter has an effect of what is happening ? If I disconnect it, I will not have any way to follow the drained current during hibernation to check the errors. As mentioned in the previous paragraph, sometimes the core wakes up alone and nothing to detect this except the drained current.

For your suggestion of the watchdog timer, I think I do not need any interrupt service routine in the program. Because if the uC will not hibernate so nothing will clear the interrupt status then cause reset and that what we need. I mean no need to use interrupt service routine then put a while(1) loop in it.

Regards,

Ahmed

Hello Ahmed,

Is it possible for you to check the HIBn pin when the uC is stuck? That will tell us if Hibernate has been requested.

Then check for VDDC to see if the Core voltage has dropped. That will confirm Hibernate and isolate the cause to a potential IO Latch Up.

I really like to have a clear ISR for every source so that code is not left to assumption. Hence the suggestion for the ISR with while(1)

Regards
Amit

Hello Amit,

May you guide me where is the HIBn pin on the Tiva C launchpad as well as where is the pin to measure the VDDC ?

Regards,
Ahmed

Hello Ahmed,

What is the full part number for the TM4C device being used?

Regards
Amit

Tiva C series TM4C123G

Hello Ahmed

Full part number as there are TM4C123G in different package options

Regards
Amit

Hello Amit,

Full part number EK-TM4C123GXL

I have added the watchdog timer to the program. I found that the program worked several times during the one hour hibernate period (the RF circuit transmitted many messages) but it is not usually doing this. That means the uC waked up from hibernate before its one hour time period and the watchdog restarted the program. This issue can be tolerated by the watchdog timer.

The other issue that confuses me is that I found current drained and portC is working (the RF circuit is controlled by PC6 in port C and I found that it was working), and I could not restart the uC. I verified it by disconnecting the peripheral connected to PC6 and found the current drained =0.

That means the uC is still in hibernate mode while portC has worked !! I had to press the sw2 to wake up the uC then restart it (because uC can not be restarted while hibernating). Do you think that portC latched any static signal ? Is there any condition the GPIO can wake up by their own while the uC is hibernating ? If so, how can I isolate the GPIO from latching any signal during hibernation ?

I think when you send me the pins to measure the VDD and HBin I may figure out more that is going on.

Regards,

Ahmed

Hello Amit,

Good news !

1-I have get a wire and rapped it to the carpet to have static then I put it near the header pins for the RF circuit and I found that it worked. The UART signal (PC4 and PC5)from uC while hibernating is still logic high so it acts like a feeding for the RF circuit. That makes the RF circuit has a positive voltage even when we switch the power off to it. This high logic and the static latches to the RF close the circuit and drains current. I have put an electrical isolator tape (like a cap) on the header pins of the RF circuit and this gives better results.

2-I can not find the H1 header to measure the hibernate pin. After finding it, what voltage am I expecting from it during hibernation ?

3-Is there any way to make the UART signal at low logic before hibernation ?

Regards,

Ahmed

Hello Amit,

Thanks for the location of H1 pin. I am sure now that the uC is hibernating. For making the PC UART a GPIO output, I used the following code lines but still have the high logic !

#define UART1_CTL_R             (*((volatile unsigned long *)0x4000D030))

UART1_CTL_R &= ~UART_CTL_UARTEN; // disable UART
GPIO_PORTC_DIR_R |= 0x30; //enable PC4-5 for output
GPIO_PORTC_AFSEL_R &= ~0x30; // not alternative
GPIO_PORTC_AMSEL_R &= ~0x30; // no analog
GPIO_PORTC_DEN_R |= 0x30; //enable digital i/o PC4-5
GPIO_PORTC_DATA_R |=0x00; //sending 0 to PC4-6 (I have tried to sent zero for the PC4-5 only and got the same high logic)
HibernateRequest();
Do you figure any mistake in the previous lines?

Regards,

Ahmed

Thanks Amit,

it works and give me zero level before hibernating. But I found that the RF circuit consider the UART as ground and there is a 5V supply connecting and it starts to drain high current :) It is better to leave the UART logic high before hibernating to stop current drainage.

To fully figure the situation, I am using a Tip120 transistor to switch on/off the RF circuit through the PC6 port. When switching ON, I am connecting the ground of the RF to the ground of the uC by giving the base of the transistor a 5V through PC6. Before hibernating, I switch OFF the transistor by setting PC6 to zero so the ground of the RF circuit is no more connected to the uC ground and is float and the RF is switched off. The 5V is always connected to the RF circuit.

When I set the UART to logic low and because they are connected to the RF circuit, it seems like it is acting as a uC ground and the circuit is switched ON !

Covering the header pins to avoid the static charges gave a good results and I will stick to this solution.

Regards,

Ahmed

Hello Ahmed,

Now that part of the circuit I am not aware of. However since the system solution holds good for your application, I would go with your judgement. There must be some other way of switching OFF the RF circuit.

Regards
Amit