Thanks for the details. Let me ask you a question. Is this a change from the previous build that didn’t contain PR116? I mean: did the serial IO connection work normally under the same scenario?
If it did work normally, it would mean that the host hasn’t sent a SCSI command to unlock the drive. If it is the case, we should break that lock after a small timeout in this situation.
Someone could confirm this by attaching a debugger to the BP when the IO connection isn’t taking any input and report the stack trace.
Thanks!
@Bus-Pirate @henrygab @grymoire @mbrugman
1 Like
@phdussud - yes, this is different. Previously, the serial I/O connected and worked as expected. See this post Bus Pirate 5 resetting itself, causing storage corruption - #36 by mbrugman
I can probably hook up my pico probe and get information for you tomorrow. It’s been a bit, so I might have some setup to do.
Thanks!
@Bus-Pirate @henrygab @grymoire
1 Like
How about I submit another PR that will break the lock after a second and if ou you can pick it up and build it and report? it would save you to debug the thing.
Thanks!
Patrick
1 Like
That would be easier. I’ll eventually want to get my debugger up and going again, but if rather do it later.
I won’t get to test it until tomorrow morning, but I’ll report back with what I find.
Thanks much for all the work and help!
Ok. It is pull request 119
@Bus-Pirate @mbrugman @henrygab @grymoire
1 Like
If the host has locked the media, it’s because it expects to be writing to the media (even if not actively doing so at the moment).
To unlock the media, the host should go through it’s safe-removal process. For Windows, that’s fairly well understood. I don’t know how Linux does this.
However, accepting the PREVENT_ALLOW_MEDIUM_REMOVAL tells the host that the media will stay around as long as the device is there. Deciding to break the lock arbitrarily is not good.
Please close this PR 119. Instead, can you prepare a PR that revers the addition of the PREVENT_ALLOW_MEDIUM_REMOVAL?
Thanks…
Here’s a fresh compile from ‘main’: "Marked sprintf() as deprecated
This will result in compile warnings, but no actual change in functionality of built images/artifacts (#118)"
Build time: 110.95 seconds
Git pull log @0d87d25:
Updating bebb8e3…0d87d25
Fast-forward
printf-4.0.0/printf.h | 2 ±
1 file changed, 1 insertion(+), 1 deletion(-)
Here’s a fresh compile from ‘main’: “Revert PR116”
Build time: 116.36 seconds
Git pull log @92bc897:
Updating 0d87d25…92bc897
Fast-forward
msc_disk.c | 20 +±-----------------
1 file changed, 2 insertions(+), 18 deletions(-)
1 Like
Using the latest version from git solved my last problem - where I could not connect to the BP.
I tried on a BP5 and BP6 and both allowed me to connect to them and execute commands.
3 Likes
Here’s a fresh compile from ‘main’: “Restore party mode, over more consistent behavior of LEDs when no config is set, or when config is set to disabled.”
Build time: 107.79 seconds
Git pull log @0ecbfbd:
Updating 92bc897…0ecbfbd
Fast-forward
pirate.c | 10 ++++++++++
pirate/rgb.c | 40 ++++++++++++++++++++++±----------------
pirate/rgb.h | 1 +
system_config.c | 2 ±
ui/ui_config.c | 4 +±-
5 files changed, 37 insertions(+), 20 deletions(-)
Here’s a fresh compile from ‘main’: “improved logic of ASCII/VT100 and toolbar configuration at start. Fixed toolbar drawing when disabled in config.”
Build time: 109.48 seconds
Git pull log @f5ef9b1:
Updating 0ecbfbd…f5ef9b1
Fast-forward
pirate.c | 36 +++++++++++++++++++++++±-----------
ui/ui_statusbar.c | 6 ++++++
ui/ui_statusbar.h | 3 +±
ui/ui_term.c | 9 ++±-----
4 files changed, 35 insertions(+), 19 deletions(-)
1 Like
Here’s a fresh compile from ‘main’: “update cls command to fix draw toolbar when not enabled”
Build time: 108.81 seconds
Git pull log @b10751f:
Updating f5ef9b1…b10751f
Fast-forward
commands/global/cls.c | 11 +++++++±–
1 file changed, 8 insertions(+), 3 deletions(-)
1 Like
Here’s a fresh compile from ‘main’: “terminal detect cleanup, now returns status”
Build time: 110.09 seconds
Git pull log @203913f:
Updating b10751f…203913f
Fast-forward
pirate.c | 4 ++±
ui/ui_term.c | 50 ++++++++++++++++++++++++++++++±------------------
ui/ui_term.h | 2 ±
3 files changed, 35 insertions(+), 21 deletions(-)
1 Like
Here’s a fresh compile from ‘main’: “cls command now reports error if not in VT100 mode.”
Build time: 106.69 seconds
Git pull log @91298e6:
Updating 203913f…91298e6
Fast-forward
commands/global/cls.c | 5 +++++
1 file changed, 5 insertions(+)
Build Failed! Logs are attached. Happy debugging!
Build time: 61.05 seconds
Git pull log @3f2d0cb:
Updating 91298e6…3f2d0cb
Fast-forward
CMakeLists.txt | 4 +
commands/global/cls.c | 2 ±
commands/global/image.c | 2 ±
display/image.py | 2 ±
display/robot5x16.bmp | Bin 0 → 153670 bytes
display/robot5x16.h | 328 ++++++++++++++++++++++++++
display/robot5xx16.bmp | Bin 0 → 153670 bytes
display/robot5xx16.h | 328 ++++++++++++++++++++++++++
display/robot6x16.bmp | Bin 0 → 153670 bytes
display/robot6x16.h | 328 ++++++++++++++++++++++++++
pirate.c | 34 +±
pirate.h | 2 +
platform/bpi-rev10.h | 2 +
platform/bpi-rev8.h | 2 +
platform/bpi-rev9.h | 2 +
platform/bpi5-rev10.h | 2 +
platform/bpi5xl-rev0.h | 2 +
platform/bpi6-rev1.h | 2 +
ui/ui_lcd.c | 602 +++++++++++++++++++++++±-----------------------
ui/ui_lcd.h | 2 ±
20 files changed, 1335 insertions(+), 311 deletions(-)
create mode 100644 display/robot5x16.bmp
create mode 100644 display/robot5x16.h
create mode 100644 display/robot5xx16.bmp
create mode 100644 display/robot5xx16.h
create mode 100644 display/robot6x16.bmp
create mode 100644 display/robot6x16.h
Here’s a fresh compile from ‘main’: “Splash screen with bus pirate logo. Can be disabled (for faster development) in pirate.h. Remove incorrect VT100 setup code.”
Build time: 108.12 seconds
Git pull log @1a9534c:
Updating 3f2d0cb…1a9534c
Fast-forward
CMakeLists.txt | 2 ±
platform/bpi-rev8.h | 2 ±
ui/ui_term.c | 2 ±
3 files changed, 3 insertions(+), 3 deletions(-)
Here’s a fresh compile from ‘main’: “New function to remove status bar for clean switching between VT100 and ASCII modes.”
Build time: 106.89 seconds
Git pull log @6a42660:
Updating 1a9534c…6a42660
Fast-forward
commands/global/cmd_mcu.c | 6 ++++±
ui/ui_statusbar.c | 10 ++++++++++
ui/ui_statusbar.h | 3 +±
3 files changed, 17 insertions(+), 2 deletions(-)
Here’s a fresh compile from ‘main’: "Safe strings phase 2 (#121)
Removed all usages of sprintf() and replaced with snprintf(). Set attribute on sprintf() to generate compile error if it is used in the future."
Build time: 104.27 seconds
Git pull log @96d092f:
Updating 6a42660…96d092f
Fast-forward
binmode/sump.c | 2 ±
printf-4.0.0/printf.h | 2 ±
system_monitor.c | 2 ±
ui/ui_statusbar.c | 107 ++++++++++++++++++++++++±------------------------
ui/ui_term.c | 7 +±-
ui/ui_term.h | 2 ±
6 files changed, 60 insertions(+), 62 deletions(-)
1 Like
Here’s a fresh compile from ‘main’: “Poll for SPI module IDLE to avoid CS while data is still exiting the buffer.”
Build time: 105.99 seconds
Git pull log @dca473f:
Updating 96d092f…dca473f
Fast-forward
pirate/hwspi.c | 1 +
1 file changed, 1 insertion(+)
Here’s a fresh compile from ‘main’: “restore unique USB number, restore splash screen”
Build time: 107.05 seconds
Git pull log @1217025:
Updating 5d7c82e…1217025
Fast-forward
pirate.c | 6 ++±–
pirate.h | 6 ++±–
2 files changed, 6 insertions(+), 6 deletions(-)