on metro_m4_express - CP3.0 FS error for specific import syntax

[jerryneedell]

WIth CP.3.0 master and 20180110 Bundle release I am running into a problem on my Metro M4 Express.
Every time I try to import adafruit_ssd1306 the system hangs then eventaully dismounts the FS and dmesg reports a read error. I have recreated and relaoded the FS several times and this is very repeatable. I am using the "py" version of the bundle, but I did verify that is also occurs with the .mpy version.
I am able open and read the lib/adafruit_ssd1306.py file.
I have run a few other program that import library modules with no problem.

After a reboot, the FS appears to actuall be OK. I can still open and read adafruit_ssd1306.py.

I just did a git pull of the master before testing this:

`Adafruit CircuitPython 3.0.0-alpha.1-53-gd201ac2-dirty on 2018-01-11; Metro M4 Express with samd51j19

import adafruit_ssd1306

system hangs until FS is dismounted

dmesg output:
694491.780411] FAT-fs (sdc1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[695481.786348] usb 3-3.2: reset full-speed USB device number 82 using xhci_hcd
[695487.130338] usb 3-3.2: device descriptor read/64, error -110`

[jerryneedell]

narrowing it down - this line causes it to hang:
from adafruit_bus_device import i2c_device, spi_device
or just
from adafruit bus_device import i2c_device
also causes hang

but
import adafruit_bus_device is OK ??

[jerryneedell]

The hang can be caused by:
from adafruit_bus_device import i2c_device
or
from adafruit_bus_device import spi_device

Adafruit CircuitPython 3.0.0-alpha.1-53-gd201ac2-dirty on 2018-01-11; Metro M4 Express with samd51j19
import adafruit_bus_device
dir()
['name', 'adafruit_bus_device']
dir(adafruit_bus_device)
['path', 'name', 'file']

[jerryneedell]

Tried loading 3.0 onto Metro M0 Express. No problems executing any of the problematic imports above.

[jerryneedell]

very interesting - making the following changes fixes the problems on the metro M4 express.
I can now import adafruit_ssd1306 !!

adafruit_ssd1306.py.dif.txt

something about
from adafruit_bus_device import i2c_device
causes the problem but
from adafruit_bus_device.i2c_device import I2CDevice
is OK???

[jerryneedell]

a bit more investigation:
the syntax:
import adafruit_bus_device.i2c_device as i2c_device
works as well
most of the modules use this syntax or
from adafruit_bus_device.i2c_device import I2CDevice

it looks like only pca9685, sdcard, ht16k33 and ssd1306 use
from adafruit_bus_device import i2c_device (or spi_device)
which causes the problem for CP3.0

[jerryneedell]

Tried recompiling under gcc 6.3.1 since this seems familiar but the problem still occurs:
from adafruit_bus_device import i2c_device
causes it to hang and dismount.

[jerryneedell]

I have narrowed down the build that introduced this problem to:
adafruit-circuitpython-metro_m4_express-20180105-5cb361c.uf2
from adafruit_bus_device import i2c_device works on builds prior to this one and fails on builds since.

[tannewt]

Thanks @jerryneedell looks like its related to Dan's 2.2 merge in 5cb361c. I'll try and take a look later this week. I don't think its related to the FS thing I mentioned earlier today on discord.

[jerryneedell]

Using J-link - so far I have determined that it is ending up in the Hard_Fault_Handler:
line 279 of port.c

 * \brief Default interrupt handler for unused IRQs.
 */
__attribute__((used)) void HardFault_Handler(void)
{
  while (true) {
        asm("");
  }
    for (uint32_t i = 0; i < 100000; i++) {
        asm("noop;");
    }
}

[jerryneedell]

here is a gdb backtrace: crashed due to "from adafruit_bus_device import i2c_device"

Loading section .text, size 0x2b2a4 lma 0x4000
Loading section .data, size 0x178 lma 0x2f2a4
Start address 0x4000, load size 177180
Transfer rate: 19225 KB/sec, 14765 bytes/write.
(gdb) mon reset
Resetting target
(gdb) c
Continuing.
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
HardFault_Handler () at supervisor/port.c:279
279	        asm("");
(gdb) backtrace
#0  HardFault_Handler () at supervisor/port.c:279
#1  <signal handler called>
#2  0x66616460 in ?? ()
#3  0x0000aa30 in mp_import_from (module=<optimized out>, name=578)
    at ../../py/runtime.c:1434
#4  0x000131fe in mp_execute_bytecode (code_state=0x2002fe94, 
    inject_exc=<optimized out>) at ../../py/vm.c:1207
#5  0x0001566c in fun_bc_call.lto_priv.308 (
    self_in=0x20001ea0 <heap.lto_priv+3200>, n_args=0, n_kw=<optimized out>, 
    args=0x0) at ../../py/objfun.c:267
#6  0x000207e8 in parse_compile_execute.lto_priv.513 (source=<optimized out>, 
    input_kind=<optimized out>, exec_flags=22, result=0x0)
    at ../../lib/utils/pyexec.c:101
#7  0x000118ac in pyexec_friendly_repl () at ../../lib/utils/pyexec.c:503
#8  main () at ../../main.c:304
(gdb) 

[tannewt]

Thanks for the backtrace! I'd suspect the culprit is frame #3. The HardFault_Handler is where it always ends up. ~Scott

…

On Mon, Jan 22, 2018 at 1:09 PM jerryneedell ***@***.***> wrote: here is a gdb backtrace: Loading section .text, size 0x2b2a4 lma 0x4000 Loading section .data, size 0x178 lma 0x2f2a4 Start address 0x4000, load size 177180 Transfer rate: 19225 KB/sec, 14765 bytes/write. (gdb) mon reset Resetting target (gdb) c Continuing. ^C Program received signal SIGTRAP, Trace/breakpoint trap. HardFault_Handler () at supervisor/port.c:279 279 asm(""); (gdb) backtrace #0 HardFault_Handler () at supervisor/port.c:279 #1 <signal handler called> #2 0x66616460 in ?? () #3 0x0000aa30 in mp_import_from (module=<optimized out>, name=578) at ../../py/runtime.c:1434 #4 0x000131fe in mp_execute_bytecode (code_state=0x2002fe94, inject_exc=<optimized out>) at ../../py/vm.c:1207 #5 0x0001566c in fun_bc_call.lto_priv.308 ( self_in=0x20001ea0 <heap.lto_priv+3200>, n_args=0, n_kw=<optimized out>, args=0x0) at ../../py/objfun.c:267 #6 0x000207e8 in parse_compile_execute.lto_priv.513 (source=<optimized out>, input_kind=<optimized out>, exec_flags=22, result=0x0) at ../../lib/utils/pyexec.c:101 #7 0x000118ac in pyexec_friendly_repl () at ../../lib/utils/pyexec.c:503 #8 main () at ../../main.c:304 (gdb) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#521 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADNqQo55hfIFYf7NAlwndCuunj1xySTks5tNPjxgaJpZM4Rbgmp> .

[dhalbert]

Reduced this to: from abd import i where
abd/i.py contains:

class I:
    pass

However, if I make the abd folder name a single letter, it sometimes crashes as before, and sometimes works. If I rename it back to abd, it crashes consistently. So seems like it's junk in RAM somewhere. Ugh. Will debug further.