have you managed to get the stack log with LOG=1 or 2 option. Also you should try to test with PC first, when it all works well, then test with RPI later on.

PS: just realize itsybitsy bsp doesn't have board_uart_read/board_uart_write implemented just yet, you need to implement that first before getting the log. I will add it later when I have time.

Build succeeded:

• dummy

RAM initialization currently passes pointers to these statics:

https://github.com/rust-embedded/msp430-rt/blob/776bd425cf3f9a5783b275e294a41380b6f8594b/src/lib.rs#L367-L376

...to r0:

https://github.com/rust-embedded/msp430-rt/blob/776bd425cf3f9a5783b275e294a41380b6f8594b/src/lib.rs#L386-L387

But since r0 will fill the entire memory range between the pointers, it ends up calling offset with values that create pointers well beyond the u32 the static is declared to contain. According to the docs of offset, this is UB:

Both the starting and resulting pointer must be either in bounds or one byte past the end of the same allocated object. Note that in Rust, every (stack-allocated) variable is considered a separate allocated object.

(every static also counts as its own "allocated object", I believe)

Moreover, the ptr::write and ptr::write_volatile calls in r0 also cause UB, because this invariant is violated:

dst must be valid for writes.

Where the validity of a pointer requires this:

For a pointer to be valid, it is necessary, but not always sufficient, that the pointer be dereferenceable: the memory range of the given size starting at the pointer must all be within the bounds of a single allocated object. Note that in Rust, every (stack-allocated) variable is considered a separate allocated object.

...but again, we are crossing between potentially many allocated objects (every static in the .data/.bss section).

Furthermore, writing to a static through a pointer not derived from that static might violate aliasing rules, but it isn't yet clear if this is the case today (I've asked the folks working on the unsafe code guidelines for clarification / guidance).

The most robust solution for this issue is to write the RAM init code in assembly instead of Rust, and run no Rust code at all until RAM is initialized.

(this issue was recently discovered to affect most -rt crates in the ecosystem; we do not believe it to cause practical issues at the moment)

I tried using my itsybitsy_m4 (SAMD51) and it has the exact same issue.

Describe the PR There has been some race condition between host software and device handling with scsi complete callback. E.g windows complain when reboot from bootloader to application since status is not yet sent to host. This fix #375

@dhalbert may want to give it a try with issue on internal flash file system on nrf52840, or maybe pointing the user with the issue to test with this.

Is your feature request related to a problem? Please describe. Currently the msc device scsi complete callback such tud_msc_write10_complete_cb() is invoked before queuing the transfer. Which can cause issue with bootloader resetting after the write10

https://github.com/adafruit/Adafruit_nRF52_Bootloader/issues/120

Describe the solution you'd like It should be either after queuing status or even after status is ack from host. Effectively revert the commit https://github.com/hathach/tinyusb/commit/605129eb6600ffb50ea2d239e0ad78a9636df8e1 states that SAMD51 + QSPI on arduino has racing issue that I had to move it before the queue !!!

There maybe issue with Arduino samd51 qspi library and/or other thing. Make sure testing this out when reverting.

Describe the PR There has been some race condition between host software and device handling with scsi complete callback. E.g windows complain when reboot from bootloader to application since status is not yet sent to host. This fix #375

@dhalbert may want to give it a try with issue on internal flash file system on nrf52840, or maybe pointing the user with the issue to test with this.

Describe the PR which return true as long as we receive the very first SETUP packet from host.

requested by @dhalbert

Describe the PR which return true as long as we receive the very first SETUP packet from host.

requested by @dhalbert

#557 slightly change the control transfer callback for the driver by introducing the stage (setup/data/ack) argument. You probably may want to update the driver. It does not change the driver much, but still need to update a bit.

I did notice this in DMESG on the raspberry pi:

[ 2.214996] usb 1-1.4: new full-speed USB device number 4 using xhci_hcd [ 2.354164] usb 1-1.4: New USB device found, idVendor=cafe, idProduct=4000, bcdDevice= 1.00 [ 2.354184] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2.354202] usb 1-1.4: Product: TinyUSB Device [ 2.354218] usb 1-1.4: Manufacturer: TinyUSB [ 2.354234] usb 1-1.4: SerialNumber: 123456 [ 2.359368] usb 1-1.4: can't set config #1, error -32

I am the one to say thanks, normally I couldn't be that fast, but thankfully this one is easy enough to fix.

@me-no-dev may need to modify IDF since the tusb_init() has been returned the incorrect code due to legacy error code (removed currently) https://github.com/espressif/esp-idf/blob/master/components/tinyusb/additions/src/tinyusb.c#L107