New v1.20.0 Release candidate v1.20.0.rc7

[robert-hh]

@tlanier said in New v1.20.0 Release candidate v1.20.0.rc7:

machine.reset() does not zero the utime.ticks_ms() counter.

That does not really matter, since utime.ticks_ms(), utime.tick_us() and utime.ticks_cpu() are not intended as absolute time stamps, but only intended as to be used for time differences in combination with utime.ticks_diff(). These counters overflow anyhow after a while.

[tlanier]

@robert-hh
My bigger concern was that the machine.reset() is not equivalent to pressing the reset button as the manual suggest. There are definite differences. One difference is the utime.ticks_ms() is not zero'ed. Another difference I discovered by accident. In our design we were having trouble with an occasional I2C bus error which was later resolved by adjusting the pull-up resistor values on the I2C bus. What was more concerning is that after the I2C bus error occurred, there seemed to be nothing I could do in software, including doing a machine.reset(), that would resolve the problem. Only a press of the reset button would allow the I2C bus to function normally again.

The question now is what else is different between a machine.reset() and a reset button press? Is there reason to believe that we should have an external watchdog that pulses the reset line of the processor to be assured that everything is properly reset after a problem occurs?

Incidentally, there are valid reasons to want the ticks_ms timer to be zero'ed after reset. If you know the program will be restarted before the timer overflows and if the timer is zero'ed after reset as you would expect, a simple subtraction would work for measuring time differences.

[robert-hh]

@tlanier I agree that machine.reset() is different from pushing the reset button, and pushing the reset button is different to a power cycle. There are obviously states which are not reset by the code running after machine.reset(). I do not know whether this can be fixed. In any case I would use an external watchdog if long term unsupported operation is needed. There are error states where the internal watchdog also fails.

[reidfo]

@robert-hh Just thinking out loud, and I haven't really looked into it yet, but could you use an output pin to trigger the reset input? If so, it would prevent having to have a separate watchdog chip (though I can also see why that would be useful).

[robert-hh]

@reidfo According to the data sheet, the reset line has to be low at least 50 µs. If you connect reset to a GPIO pin, that cannot be guaranteed, or even the reset may not be released. Different to others, the ESP32 chip does not have a separate reset input. The pin used for that is CHIP_PU, which powers the chip or at least most of it up/down. So you would anyhow need something like a pulse extender to ensure a proper reset signal. And that must be more than a RC circuit.
Edit: Looking at typical devices, there is a RC circuit at the reset with a time constant of 1 ms (10k & 100nF). So using that might work.

[robert-hh]

@reidfo SO I tried that. The only Pin that worked for that purpose was P23. All other Pins caused a freeze or constant reset loop. And P23 is used for the SD card. The command sequence was like:

>>> from machine import Pin
>>> p=Pin("P23", Pin.IN)
>>> p(1)
>>> p=Pin("P23", Pin.OUT)
>>> p(0)

Setting the Pin to IN first and then p(1) ensures, that when switched to OUT mode the value is high.

[reidfo]

@robert-hh What pin did you connect P23 to? Did it successfully reset your board?

[robert-hh]

@reidfo The connection was between P23 and Reset (what else). And yes, it did reset the board and the board booted in a normal fashion. The board should have an RC lowpass at Reset to suppress bouncing of the push button.