Page 1 of 2

Debugging boot, safe mode ?

Posted: Tue Jun 04, 2019 6:40 pm
by Niallp
Hello,

I've been working around inconsistent booting for a while now but moving to deployment I really need to get the boards to boot consistently or they'll be useless in the field. The problem I am seeing is inconsistent booting ... the boards will hang on reset for about 10s, then go directly to REPL without executing boot.py.

This has occurred with multiple board types, WiPy, esp8266 and stm32 though I'm concentrating for now on our stm32 board (custom but mostly based on a Nucleo STM32L476RG). I'll get good boots most consistently on full power cycling, with nRESET low and machine.reset() more likely to fail than not.

Not seeing anything on the serial console, just the delay booting up and no led test (part of boot.py). I was wondering if somehow safe mode is being set and a cap is holding a line up/down somewhere it initiate it but can't find a reference to it in mpconfigboard.h or other config files. It looks like it might only be part of the cc3200 family though I have seen references in the forum to it on the esp8266.

Any pointers appreciated, in particular whether or not safe mode might have any relevance, thanks.

... Niall

Re: Debugging boot, safe mode ?

Posted: Tue Jun 04, 2019 7:41 pm
by kevinkk525
Interesting, I have never seen that behavior. Not on my esp8266 nor on my Esp32

Try adding this to your boot.py before executing any of your code:

import utime
utime.sleep_ms(100)

Re: Debugging boot, safe mode ?

Posted: Tue Jun 04, 2019 7:57 pm
by dhylands
Are you running a linux system? If so then check to see if you have modemmanager installed and uninstall it. modemmanager will open serial ports that looks like modems and send AT commands to them.

Re: Debugging boot, safe mode ?

Posted: Tue Jun 04, 2019 9:09 pm
by Niallp
kevinkk525 wrote:
Tue Jun 04, 2019 7:41 pm
Interesting, I have never seen that behavior. Not on my esp8266 nor on my Esp32

Try adding this to your boot.py before executing any of your code:

import utime
utime.sleep_ms(100)
No difference ... I don't think the board is making it to boot.py or the first couple lines for the LED would run.

I don't have as thorough data for my esp8266 boards but all the appearance of a similar problem ... after running a while with deep sleep, using boot.py to determine wakeup type and sample appropriately, the board stops the sleep/wake cycle and when I connect a console it is just sitting waiting at REPL.

Re: Debugging boot, safe mode ?

Posted: Tue Jun 04, 2019 9:15 pm
by Niallp
dhylands wrote:
Tue Jun 04, 2019 7:57 pm
Are you running a linux system? If so then check to see if you have modemmanager installed and uninstall it. modemmanager will open serial ports that looks like modems and send AT commands to them.
Yes and in earlier development I did notice it dumping crap onto the console, symptom being a syntax error ... modem manager removed and now get clean starts.

Code: Select all

[14:03:09] Disconnected
[14:03:22] Connected
MicroPython v1.11-37-gb9fa736f7 on 2019-06-04; CHS-FX1 with STM32L476RG
Type "help()" for more information.
>>> 
whereas my boot.py should have just cycled the RGB LED and then passed off to the logger code.

Code: Select all

# boot.py -- run on boot-up
# can run arbitrary Python, but best to keep it minimal

from machine import Pin
red = Pin("LED_RED",Pin.OUT)
blu = Pin("LED_BLUE",Pin.OUT)
grn = Pin("LED_GREEN",Pin.OUT)
red.value(1)
blu.value(1)
grn.value(1)
red.value(0)
blu.value(0)
grn.value(0)

# enable Vbat charging. default 100 nF should give RTC 0.67 s hold up
# if only backup registers then should keep up for 22 s
# larger caps for longer life ... 0.22F gives 17 days of RTC, BR only for > 1 yr
import stm
stm.mem32[stm.PWR+stm.PWR_CR4] = 0x300

import pyb
pyb.main('loggerSD.py') # main script to run after this one
#pyb.usb_mode('VCP+MSC') # act as a serial and a storage device
#pyb.usb_mode('VCP+HID') # act as a serial device and a mouse

Re: Debugging boot, safe mode ?

Posted: Tue Jun 04, 2019 9:38 pm
by dhylands
Do you have anything connected to X17? That's also connected to the USR button.

There is a pullup resistor on the line (to pull USR to 3.3v when the button isn't pressed). if it had a cold solder joint then the line might float. You could try adding an external pullup resistor between X17 and 3.3v to see if it makes any difference. You couild also use X17 to monitor the USR signal. It should be at 3.3v all of the time.

Once you get the REPL, if you press Control-D, then boot.py should be executed again. I normally put a print in the first line as confirmation that it gets executed.

Re: Debugging boot, safe mode ?

Posted: Wed Jun 05, 2019 12:04 am
by Niallp
dhylands wrote:
Tue Jun 04, 2019 9:38 pm
Do you have anything connected to X17? That's also connected to the USR button.

There is a pullup resistor on the line (to pull USR to 3.3v when the button isn't pressed). if it had a cold solder joint then the line might float. You could try adding an external pullup resistor between X17 and 3.3v to see if it makes any difference. You couild also use X17 to monitor the USR signal. It should be at 3.3v all of the time.

Once you get the REPL, if you press Control-D, then boot.py should be executed again. I normally put a print in the first line as confirmation that it gets executed.
That sounds like a possible lead ... which version of the pyboard has the pullup on X17 ? (PB3) ... can't see it on the 1.0 or 1.1 schematics.

My board is a custom one based on the Nucleo so PB3 is used for SWO ... no pullup/down or other connections (unless within the st-link pod) and generally has been unconnected for these tests (though just tried it with the st-link, not noticeably different). I'm wondering if this might be related to my other problems viewtopic.php?f=12&t=5903 with the st-link failing to deploy MicroPython sometimes.

Is X17 and the USR button intended to invoke safe mode and bypass boot.py ? ... I'll dig into the source and see what I find.

Re: Debugging boot, safe mode ?

Posted: Wed Jun 05, 2019 12:11 am
by dhylands
In the pyboiard schematics:
https://raw.githubusercontent.com/micro ... YBv10b.pdf
The USR button is at the very bottom of the page near the center.

You configure which pin is the USR button in your mpconfigboard.h
https://github.com/micropython/micropyt ... board.h#L4
https://github.com/micropython/micropyt ... .h#L75-L79

Whatever pin is configured there will be the pin that the code looks for to determine the boot mode.

Re: Debugging boot, safe mode ?

Posted: Wed Jun 05, 2019 12:38 am
by dhylands
And to answer your other question, yes the USR button is used to manipulate the various boot modes.
See: http://docs.micropython.org/en/latest/w ... light=boot

The update_reset_mode function determines what the boot mode is:
https://github.com/micropython/micropyt ... ain.c#L293

Re: Debugging boot, safe mode ?

Posted: Wed Jun 05, 2019 8:32 pm
by Niallp
dhylands wrote:
Wed Jun 05, 2019 12:11 am
In the pyboiard schematics:
https://raw.githubusercontent.com/micro ... YBv10b.pdf
The USR button is at the very bottom of the page near the center.

You configure which pin is the USR button in your mpconfigboard.h
https://github.com/micropython/micropyt ... board.h#L4
https://github.com/micropython/micropyt ... .h#L75-L79

Whatever pin is configured there will be the pin that the code looks for to determine the boot mode.
OK, that was the schematic I was looking at, the resistor R17 isn't what I'd describe as a pullup but rather a switchable pulldown, hence my confusion. The actual pullup is the one internal to the micro and configured via GPIO_PULLUP.

... and it turns out that was my problem ! I had already switched the pin to PA9 but had left the pullup not configured so the USR pin was not at a consistent state. With either external pullup or enabling the pullup on PA9 with GPIO_PULLUP I am now getting consistent booting using boot.py :D :D :D

Thanks very much for the help !