all leds cycling

[smhodge]

I can't find in the documentation what all 4 leds successively cycling on/off means.

I am having this issue at random with trying to establish a connection (with rshell) to a pyboard v1.1 (v1.12 software). Resetting the board to factory defaults does not fix it.

Thanks

[jimmo]

So the sequence is the four colors individually?

And if you hold down USR instead you get the green/orange/green+orange sequence (which I assume is how you did the factory reset?)

[pythoncoder]

This is surprising. It might help if you told us some more about your setup. Your OS. Your rshell invocation line. If you're using Linux have you got a udev rule for the Pyboard?

[smhodge]

Leds: red on, green on, yellow on, blue on (all 4 are then on), red off, green off, yellow off, blue off (all 4 are then off) ... then starts all over. Each on or off period is about a second. I've never written code that does that so I know it's not mine (smile).

Windows 10 OS. I use a batch file to invoke the rsync option with rshell:

cd (to directory containing source *.py files)
python "C:\Program Files\Python37\Lib\site-packages\rshell\main.py" rsync -m . /flash
pause

The problem is it fails to connect. Here is the output from rshell:

Connecting to COM4 (buffer-size 512)...
Trying to connect to REPL .....

The dots after "REPL" built up; it always hangs after 5 dots, with no further message.

The frustrating thing is that this all worked just fine for several months (well over 100 times), then just starting doing the above about a month ago, with no change to the firmware on the board (v1.12). Moreover, it is not consistent. It will works ok for 2 or 3 "uses" in a row (which allows me to continue developing code) and then it fails. I then press the RST button on the pyboard (which restarts my code that is loaded on it) amd try again. Eventually after from 2 to 10 or so such RST tries it will "take" and all is ok for another 2 or 3 "uses" and then once again, it's use the RST button until it is (temporarily) ok again.

I've tried resetting the board to factory defaults several times and that doesn't fix it.

True my code has been slowly growing larger over the months but I think I'm still ok. Using mem_info() I have about 60% free. But it seems doubtful it's a problem with my code since it's a "connect to REPL" issue, and occassionally/eventually it does connect. Once it connects, all goes just fine.

FWIW, here is my boot.py file (which has not changed in months):

import machine
import pyb
pyb.main('COS.py') # COS.py is my "main" file
pyb.usb_mode('VCP')

Steve

[jimmo]

That sequence of LEDs is triggered by the "fatal error" handler, which has a few different sources:
- threading (e.g. deadlock detected,
- CPU hard fault
- startup configuration of clocks
- uart configuration
- low-level uncaught exception

(Most of these should be impossible to trigger from Python code, so this does suggest a firmware or hardware issue).

I guess some basic troubleshooting questions:
- Do you see any issues if you go back to firmware v1.11? (Or up to the latest nightly build)
- Can you try doing a full erase flash (see viewtopic.php?f=6&t=7856#p44776 )
- Do you see issues if you don't copy your code to the board (i.e just use the REPL or simpler programs).

[smhodge]

Thanks. It's good to know what it means. I'll work on those tests and post in a day or two.

[smhodge]

OK, I'm getting the issue narrowed down. I did the bulk erase, as well as in the process upgraded the firmware to v1.12 from v1.11. Same issue, so that didn't solve it.

On a hunch based on some other weird things that had been going on at startup for a few months (which I had a workaround kludge fix for), I commented out all use of I2C. That solved both those weird things and the REPL leds cycling issue. I isolated that to just the act of creating the I2C object initially. I also use SPI for two devices (an external RTC and flash memory) and that works just fine.

The very first lines of my code are:

from pyb import I2C, SPI # Plus other stuff
spi = SPI(2)
spi.init(SPI.MASTER, phase=1) # SPI works fine
i2c = I2C(1) # Comment these 2 lines out and all is ok(above)
i2c.init(I2C.MASTER)

If I use the REPL directly to test these lines and the code that uses I2C for 4 devices it all works just fine.

Thoughts would be much appreciated.

[jimmo]

Interesting!

I don't really have any good suggestions, but just in an effort to rule things out, can you try using machine.I2C (and machine.SPI) instead of pyb.I2C?

The pyb classes are all deprecated. In some cases (e.g. UART and Pin), machine.Pin and pyb.Pin are actually the same, but for I2C they are different implementations.

[pythoncoder]

The pyb classes are all deprecated.

That seems a sweeping statement. The pyb classes offer STM-specific functionality which is not present in machine. For example timer channels.

@smhodge The only way I can see to debug this is to try to identify the specific usage of I2C which is causing the crash. You could comment them out selectively, or log each usage to figure out where the crash occurred.

[jimmo]

That seems a sweeping statement. The pyb classes offer STM-specific functionality which is not present in machine. For example timer channels.

Yes, that is a good point.

Maybe better phrased as "the pyb classes are slated to be replaced as the machine API is better defined to cover the missing functionality" (but this may take a long time and the existing ones are still supported in the meantime). However for maintaining compatibility, if the machine API supports your use case, using the machine ones is a good idea. (And for i2c and spi masters, this should be the case).

But because they do have a different implementation, just thought it might be a useful diagnostic hint if there was any difference for this issue.