Flashing internal memory thru DFU Bootloader

[gcastoldi]

Is it possible to flash the internal memory of a blank STM32L496ZG through USB? The device has Boot0 pulled down to GND, but all the memory banks are blank, from the application note it's unclear whether the MCU executes the embedded system bootloader in these conditions or not. From my understanding of it, since the flash memory is empty, the MCU uses the internal bootloader, and since a USB port is connected to it, it should be possible to use DFU. It is again unclear to me if it's possible to send a payload to flash the internal memory through DFU, without losing the possibility of executing the system bootloader once again.

[Tesla DeLorean]

You have any debugger access in this design?

You should be able to check boot loader signs of life via USARTs described in AN2606. Noise on these might be interpreted as connection attempts.

Does USB work from user space code?

Does the crystal start promptly?

Tying BOOT0 to GND, in a manner you can't change, seems like an unhelpful design choice.

As I recall this should go into the boot loader at power-up with a blank device, a reset might not.

You'd have to initiate re-entry from user space, but if that's working why not implement your own DFU Device?

[gcastoldi]

No debugger access is available directly to this device, but a second microcontroller is connected to this one through RS 485, and this second one is connected to a JTAG interface. Boot0 is pulled down through a resistor, so it can be left floating if needed. So what you are saying is that technically I should be able to plug the device's USB and detect/send a payload it through bash, right?

[MM..1]

is any from this true? = Systembootloader start. Normal way i sprepare design for this.

[gcastoldi]

I've seen this table, but nowhere else nboot is cited, so i have no idea if those are 1 or 0

[MM..1]

Option bits is described on other places, but connect STLink and read it is first step.

Boot0(pin) describe external pin state. What isnt clean?