| *** tpb has joined #tomu | 00:00 | |
| im-tomu | [tcal-x] Hmm, I'm not having any luck with the tinyusb examples (`cdc_msc`, `cdc_dual_ports`, `board_test`), or even circuitpython (the adafruit download). In each case after loading the .dfu, the Fomu LED goes into a breathing red pattern, and the USB disappears (not seen in dfu-util -l, or lsusb), and there's no new device in /dev/. Maybe my udev rules are misconfigured? I found these: | 04:50 |
|---|---|---|
| im-tomu | ``` | 04:50 |
| im-tomu | $ cat /etc/udev/rules.d/99-fomu.rules | 04:50 |
| im-tomu | SUBSYSTEM=="usb", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="5bf0", MODE="0664", GROUP="plugdev" | 04:50 |
| im-tomu | $ cat /etc/udev/rules.d/80-fpga-serial.rules | 04:50 |
| im-tomu | # Disable ModemManager for BlackIce | 04:50 |
| im-tomu | ATTRS{idVendor}=="0483", ATTRS{idProduct}=="5740", ENV{ID_MM_DEVICE_IGNORE}="1" | 04:50 |
| im-tomu | # Disable ModemManager for TinyFPGA B2 | 04:50 |
| im-tomu | ATTRS{idVendor}=="1209", ATTRS{idProduct}=="2100", ENV{ID_MM_DEVICE_IGNORE}="1" | 04:50 |
| im-tomu | # Disable ModemManager for TinyFPGA BX | 04:51 |
| im-tomu | ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="6130", ENV{ID_MM_DEVICE_IGNORE}="1" | 04:51 |
| im-tomu | ``` | 04:51 |
| im-tomu | [tcal-x] `micropython-fomu.dfu` from the workshop works fine; it appears on /dev/ACM0. | 04:51 |
| xobs | You're running 2.0.3, right? | 04:57 |
| im-tomu | [tcal-x] Yep | 04:58 |
| im-tomu | [tcal-x] Wait, just now, I'm seeing /dev/ttyACM0 from the cdc_msc example...now I need to mount it? | 04:59 |
| xobs | Both shouid work at the same time. | 05:01 |
| im-tomu | [tcal-x] Oh, I tried picocom, and I saw "TinyUSB CDC MSC device example"...so something seems to work. | 05:01 |
| im-tomu | [tcal-x] Ok, it seems I'm unstuck; not sure what my problem was. Thanks! | 05:03 |
| im-tomu | [tcal-x] Ok, I realized I was mixing up my Fomus. The one I was using had v2.0.3-55-ge928b86 -- a build from the current master HEAD -- and that's what wasn't working. When I reverted to v2.0.3, cdc_msc started working. So it /seems/ something added since the v2.0.3 release is not working well with tinyusb. | 06:20 |
| xobs | I see. That's problematic then. | 06:44 |
| *** CarlFK has joined #tomu | 07:12 | |
| *** CarlFK has quit IRC | 08:25 | |
| *** y2kbugger has quit IRC | 08:36 | |
| *** flammit has quit IRC | 08:37 | |
| *** y2kbugger has joined #tomu | 08:37 | |
| *** guan has quit IRC | 08:37 | |
| *** ukembedded has quit IRC | 08:37 | |
| *** flammit has joined #tomu | 08:38 | |
| *** ukembedded has joined #tomu | 08:38 | |
| *** guan has joined #tomu | 08:39 | |
| *** y2kbugger has quit IRC | 08:42 | |
| *** flammit has quit IRC | 08:44 | |
| *** flammit has joined #tomu | 08:46 | |
| *** y2kbugger has joined #tomu | 08:47 | |
| *** CarlFK has joined #tomu | 08:53 | |
| *** im-tomu has left #tomu | 10:42 | |
| *** im-tomu has joined #tomu | 10:42 | |
| im-tomu | [umarcor] @xobs thanks for merging im-tomu/fomu-workshop#333 ! | 16:13 |
| im-tomu | Can we now merge im-tomu/fomu-workshop#352 ? That would then combine im-tomu/fomu-workshop#353 and im-tomu/fomu-workshop#357 into a single update. | 16:13 |
| *** im-tomu has left #tomu | 16:22 | |
| *** im-tomu has joined #tomu | 16:22 | |
| *** im-tomu has left #tomu | 16:28 | |
| *** im-tomu has joined #tomu | 16:29 | |
| *** im-tomu has left #tomu | 16:37 | |
| *** im-tomu has joined #tomu | 16:37 | |
| *** CarlFK has quit IRC | 17:07 | |
| im-tomu | [umarcor] @tcal-x, I'm about to fix a few issues related to the docs (e.g. im-tomu/fomu-workshop#96). What's the state of im-tomu/fomu-workshop#350 ? | 17:09 |
| *** CarlFK has joined #tomu | 17:43 | |
| im-tomu | [tcal-x] Sorry it escaped my attention. It's good the way it is, ready to merge. | 18:41 |
| im-tomu | [tcal-x] @umarcor can you give it a quick re-review? The re-review button isn't working for me. | 18:44 |
| *** im-tomu has left #tomu | 19:29 | |
| *** im-tomu has joined #tomu | 19:29 | |
| jljusten | Is the fomu workshop riscv-blink compatible with foboot 2.0.3? | 20:57 |
| jljusten | I think msleep in main.c might not ever be finishing for me. | 20:58 |
| jljusten | And, wishbone-tool no longer sees the device after I load the .dfu | 20:59 |
| im-tomu | [tcal-x] Yes, riscv-blink should work with foboot 2.0.3. What does the LED do after you do the `dfu-util -D riscv-blink.dfu` ? | 21:57 |
| jljusten | it turns red, and appears to be in the breathe mode as programmed in rgb_init(). but, the color never changes. | 22:06 |
| im-tomu | [tcal-x] Sometimes just power cycling and trying again will get it to work. | 22:07 |
| acathla | jljusten, I got the same problem with one of my fomus | 22:08 |
| acathla | But no real solution yet | 22:08 |
| im-tomu | [tcal-x] I also can reproduce the problem on one of my fomus. The red breathing pattern usually means an error, or in this case, at least the program on the CPU is not running correctly. | 22:10 |
| jljusten | I am using a distro gcc cross compiler for riscv32, rather than using get-toolchain.py. But, the compiler appears to be working ok. | 22:11 |
| im-tomu | [tcal-x] I just did a quick experiment. I replaced the 2.0.3 foboot with 2.0.2 on the Fomu that showed blinking red. With v2.0.2, riscv-blink started working. I'm not suggesting you try it since it's potentially risky, and you will lose other fixes in 2.0.3. But if it becomes your only option... | 22:16 |
| jljusten | it definitely seems like msleep() is not working. before the loop, I added `color_wheel(86); msleep(80);`, and then it only turns green. | 22:22 |
| jljusten | If I remove the msleep() call before the loop, then it enters the loop, and sets the color to red. So, I guess it then gets stuck on the msleep() inside the loop. | 22:24 |
| jljusten | But, I think there must be more problems than only msleep(), because isr() doesn't seem to be working to handle the usb interrupts. (`wishbone-tool -s gdb` no longer works after loading the .dfu) | 22:29 |
| im-tomu | [tcal-x] Interesting...you could try putting some more LED color-changing commands inside msleep() (in src/time.c), or try replacing the timer0 calls with a busy loop. | 22:29 |
| im-tomu | [tcal-x] Yeah, I was assuming msleep() was based on a timer interrupt, but then the isr() didn't have anything timer-related, so I saw that msleep directly accesses the timer... | 22:31 |
| im-tomu | [tcal-x] With wishbone-tool, using it just to peek 0x0, it would work one invocation, then not work 5 seconds later. So it's worth trying it a few times. I can't speculate what the issue is, unless there's some path that barely meets timing. | 22:32 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!