[SOLVED] External interrupt minimum rise time requirements?

[newguy]

Processors: PIC18LF24K40, PIC18LF25K40, PIC18LF26K40 (behaviour observed on all)

Compiler versions: 5.087, 5.091 (behaviour observed on all).

Application: very low power deep sleep application (processor clock halted), external sensor generates a rising edge on a line routed back to external interrupt 0 (INT_EXT using PPS to set up the appropriate pin).

Observed behaviour: some units, sometimes, will lock up. The external sensor which generates the rising edge actually does so - I can scope that line and observe it go high, but the processor doesn't wake from sleep. It's not a race condition regarding the line going high before I enable the INT_EXT interrupt because I essentially disable the sensor until just before I put the PIC to sleep, and the sensor has been configured to sleep for 10 seconds before performing a measurement and hence asserting its external interrupt line high.

Avenues I'm exploring as to cause:
1. The PIC requires some minimum V/s rise on the external interrupt, and this minimum speed isn't being met. I've scoured the data sheets and can't find any mention of a minimum slew rate, only that the line needs to be high for a minimum of 25ns in order to be detected. This requirement is definitely being met.
2. I'm using PMD to essentially shut down all non-essential peripherals before going to sleep, then immediately re-powering and re-initializing them upon wake from sleep. One of these peripherals, the MSSP (external sensor which wakes the processor is connected via I2C, other than for the active high interrupt line) must be re-initialized prior to accessing the sensor itself. I think the program might be hanging during that step for whatever reason. I do have a generic delay after re-powering the peripherals (via PMD) before attempting to re-initializing them, but I strongly suspect that the specific delay isn't adequate under all circumstances.

If anyone has encountered a minimum slew rate on an external interrupt in order to be recognized, please chime in. Regarding 2), I'll be experimenting and will report back if I find anything significant.

[PCM programmer]

Test the theory that it's rise-time:

1. Put in a couple 74AHCT14 schmitt-trigger inverters inline with the
sensor signal, to clean up the waveform and make a fast rise-time.
See if the problem goes away.

-or-

2. Put in a push-button with hardware debounce, to get a clean signal.
Then feed that to an RC. See when or if it fails.

Also, it would be helpful if you would post your code that puts the PIC
into Deep Sleep, and the code that it executes after it wakes up.
Also, tell us the PIC Vdd, and the processor oscillator frequency.

[Ttelmah]

What pin are you using?.
Makes a difference, since the ones with schmitt input buffers should
automatically not worry about the slew rate.
If you are not using a schmitt input, try using one and see if the behaviour
changes.

Remember the clock can take quite a long time to stabilise after waking.
Wonder if this could be causing a problem with your re-initialisation.

Suspect '2' is the most likely problem. Question then is what/why?.
When you are turning the peripheral 'off', remember that the I/O pin may
then go 'back' to being controlled by the standard I/O on the PIC, rather
than the peripheral. Make sure the pins have been tri-stated before you
do this. Might be generating an unexpected signal to the peripheral that
leaves the bus in an unusual state. Similarly when you switch the
peripheral back 'on', are you sure it wakes with the pins in the idle state
you expect?. I'm wondering if somewhere in the off/on process you are
getting the bus into an unexpected state....

[Ttelmah]

As a further comment, you say that the INT is active for more than 25nSec.
This is not enough time by a huge margin. Tinp (the time needed for the
interrupt to be detected), is specified as Tcy. So it has to be active for
one entire instruction cycle time to be detected.

TINP INT pin High or Low Time TCY — — ns

Tcy is the minimum. There is no maximum or typical figure.

It is 'strange', since if you have the clock stopped there is no 'Tcy', but
Microchip said to me that the figure required is the same as the fastest
the chip can run. So if the chip supports 16MIPS 'max' the minimum
time to guarantee INT detection becomes 1/16000000 sec.

[newguy]

Sorry I wasn't clear. What I meant is that the data sheet states 25ns minimum for the high time in order to be detected, but I'm sometimes seeing hours when it hangs. Therefore I know that the unit *has* to have awakened.

More evidence to steer me in the right direction: the sensor can be triggered to perform an immediate wake up via a magnet and a reed switch, but that functionality is "locked out" when this happens, which is pointing me toward the code hanging in an infinite loop.

Clock stabilization: never considered that, and a very likely culprit. Will add code to wait until the stabilization flag/bit gets set upon wakeup from sleep. Will also examine all places where there might be an infinite loop.

I did find one unit last night where the external sensor seemed starved for solder so I pulled it, put down a wee bit more paste, and then reflowed it. That problematic unit is no longer being problematic, but I've only left it running overnight, so not really enough time to see if the problem has gone away or not.

[temtronic]

just a comment..
Since you're putting PIC to sleep, that implies battery operation,so..... have you got really,really good batteries with LOTS of current capacity AND do you wait long enough when 'waking up' to have the PIC properly stabilzed for proper running ?

Jay

[newguy]

Regular alkaline AA x 2. Original prototype (LoRaWAN sensor) has been running for about 6 months (give or take a couple weeks) and is just shy of 700,000 transmissions so far. The batteries are down to about 2.50V right now. The PIC can run down to something like 1.7V (have to check) but the transmitter module is only rated down to 2.3V. Still have some life left in them. Power isn't an issue I don't think.

[temtronic]

The potential problem with battery operation is the current demand vs voltage. Typically when there's a demand for higher current( say transmitting), the battery voltage drops or dips. This dip could cause the PIC to react oddly .
I've seen this time and again over the decades and it's more pronounced when the device is in the cold Real World and not on the bench, in a nice warm room.

[newguy]

I absolutely agree. However, I don't think battery voltage is the root cause. Here's why:

- Device sleeps for many tens of seconds at a time. Transmitter is in deep sleep, consuming just a few uA. Processor draws ~50nA and external sensor, which wakes the processor draws ~1uA.
- External sensor wakes processor, and internal RC clock activates. Processor draws ~300uA while awake.
- If required, processor wakes up transmitter, which draws ~3mA idle, ~100mA transmitting.
- Processor places transmitter in deep sleep, finishes some housekeeping, then places itself in deep sleep again.

Problem exists independent of battery state. Seems to be a waking issue but as I've said, it's hard to pin down given that I have finished PCBs, so my troubleshooting options are limited.

[Ttelmah]

Potentially, if you have a pin available, you could signal as soon as the
chip wakes. Then it'd make it possible to know if the issue was with the
act of waking, or the peripheral re-initialisation
You have got a nop following the sleep instruction?.
This is required, or wake can be unreliable.

[temtronic]

re:

[Ttelmah]

Again the comment about posting the sleep code. My allow us to see
something.
Thoughts going through my head are that something in the code might
result in PEIE becoming disabled.
Also what is the clock configuration?.
Thought that there may be an issue with the clock not starting.
Are you changing oscillator speeds?. There can be issues if sleep is
triggered before an oscillator switch has completed. If this happens the
chip will wake with the 'old' oscillator selected.

[PCM programmer]

I said in my post:

[Ttelmah]

Exactly.
That is why I said 'again'.

[newguy]

Sorry guys. Was neck deep in that project all day yesterday and again all day today; about 12h each day.

The primary source of my problems was that the external sensor I mentioned was setting its external interrupt out line Hi-Z *after* it asserted it high to wake the processor. Hi-Z connected to PIC input = bad times for me, as my code had a while (input(SENSOR_INTERRUPT)); line to wait for it to go low after I read the sensor (which clears its interrupt out line, but only if it's configured to actually drive it).

It was doing so because I had a typo in one of the configuration word settings and I couldn't see it for the life of me. The device sort of worked sometimes because I was toggling the sensor's setting governing that line to be driven, then not, then driven again. I'm surprised it worked at times because it shouldn't have. It really shouldn't have.

Anyway, I'm pretty sure I have it licked. Just started a 24h test to see if the sucker locks up again, but I rather doubt it will now.

Cheers,

Edit: Re: posting code, I did try cutting the code down to something small which still showed the problem, but that small program ran fine. That's why I spent all day digging.