TypeError while generating stubs from board via USB #400
Labels
bug
Something isn't working
Comments
|
@trepidacious I will take a deeper look into this this weekend, but one thing I'm curious about is whether you see the same behavior when using the rshell backend (via That would help narrow down where the root of the issue is (stub repo/management or pyb with pydevice backend, otherwise). |
|
@BradenM You're very welcome, thanks for the really useful tool! :) I've tried running with that option but I get an error, not sure whether I'm using the right params? $micropy stubs create --backend rshell /dev/cu.usbmodem11201
Usage: micropy stubs create [OPTIONS] PORT
Try 'micropy stubs create --help' for help.
Error: No such option: --backendI can only see
One thing I forgot to mention - following the docs for creating stubs I ran Not sure whether that means I'm missing a dependency? |
|
@trepidacious 🙃 Sorry about that. That said, it looks as if I may have already solved this issue in #394: I intend on pushing out a prelease once I get it merged (or at most soon after). I will leave this issue open for now so others may find your workaround if needed. |
This is expected. The |
|
@BradenM Ah that's great - I'll stand by for the prerelease, thanks! |
|
@trepidacious |
|
@BradenM Thanks, I've had a look and unfortunately I still get an error, it seems to be different now though: I used I've repeated a few times with the same results - it looks like nothing is produced in
|
|
Just realised I'd chopped off a bit too much - there's also a "Failed to create the report" message earlier in the output: I grabbed a copy of the files that had been copied to the temp directory at the point the script fails, interestingly the last few are 0 bytes, these are also the files that display "[0.00/0.00 @ ?B/s]" in the micropy output. The file names also stop before the end of the list above - there's nothing after |
|
I've now tried again with a Pico Lipo with 16MB of flash, and that completes successfully - the Pico W only has 2MB of flash, and I believe some additional libraries. Of course it might be something other than the flash size causing the difference... |
|
@trepidacious Your suspicion on the flash size is certainly plausible. I've just pushed out Namely, this includes Although compiling w/ mpy-cross would be ideal here -- I have not yet implemented it. Meanwhile, I'm curious to see what results you achieve toying around with the variant option and the two provide backends. If you find the time, please let me know what you find. Thanks! |
|
Hi, thanks for the update - I've repeated the test on a Pico W with each of the options for |
|
@trepidacious Thank you for the update! Looking at this now, it seems clear what is most likely occurring. The pydevice backend has logic built into it that attempts to circumvent OOM errors by automatically rebooting the device and reducing the buffer size used for reading from the device. However, this logic works with the expectation that reads (and/or pydevice) throw exceptions / errors during the read. What seems to be happening is it's just reading nothing. So, while it remains true that compiling beforehand via mpy-cross would likely prevent (not solve) this issue, I will revisit this logic and implement improved checks to ensure the integrity of the files. This will also be needed for #312 (comment) and related issues (and its probaby something I should have done from the get go... 😬 ) Thank you again @trepidacious for your time in helping me iron these issues out. Much appreciated. |
|
@trepidacious Hi, finally found the time to get another release out. Mpy cross compilation and file integrity verification are in, so this should be the one 🤞 |
|
Going to go ahead and close this out. Please reach out to me if any issues arise and it needs to be opened, thanks! |
|
I've been running into this for a few hours now. Here's my logs. Looks like mpy cross compile is plain failing, and it's not possible to diable the cross compiling via command lien options either.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
micropy fails to generate stubs from a PicoW board running Pimoroni Micropython, when no other stubs exist.
Expected Behavior
Micropy generates stubs successfully.
Current Behavior
Micropy produces a
TypeErrorand doesn't generate the stubs.Steps to Reproduce
rm -rf ~/.micropymicropy stubs create /dev/cu.usbmodem11201Possible Solution
For me, adding
straroundnamein the line"/".join([package.repo_name, name])inresolve_packagefunction ofrepo.pyfixed the issue.Once the stubs have generated once with this change, the unmodified code works fine - seems to be something about having no stubs, or maybe not having an existing version of the same-named stubs?
Logs
The last section of output from
micropy stubs create /dev/cu.usbmodem11201- everything before this looks normal:micropy.log
Context (Environment)
The text was updated successfully, but these errors were encountered: