Open biomurph opened 3 years ago
I have related issue on the feather sense.
I am updating the bootloader as described here. That works fine but the feather does not come out of DFU. I have to manually copy UF2 CircuitPython image. Then the device comes out of DFU and runs the old sketch which is fine as I wanted to only update the bootloader.
Hey, I think I'm experiencing the same issue. I can only get my custom board to operate again with a power cycle, or by uploading my sketch via a J-Link, THEN uploading via DFU from the Arduino IDE.
The bootloader seems to crash when it's invoked, and I have to remove the USB cable from my PC to get it to exit the firmware update attempt after it hangs:
Upgrading target on /dev/cu.usbmodem2401 with DFU package /private/var/folders/5l/4y41_qpx4275kq7nd21gwjf40000gn/T/arduino_build_338225/controller.ino.zip. Flow control is disabled, Single bank, Touch disabled
Opened serial port /dev/cu.usbmodem2401
Failed to upgrade target. Error is: [Errno 6] Device not configured
Traceback (most recent call last):
File "nordicsemi/__main__.py", line 294, in serial
File "nordicsemi/dfu/dfu.py", line 235, in dfu_send_images
File "nordicsemi/dfu/dfu.py", line 157, in _dfu_send_image
File "nordicsemi/dfu/dfu_transport_serial.py", line 124, in open
File "serial/serialutil.py", line 599, in setDTR
File "serial/serialutil.py", line 469, in dtr
File "serial/serialposix.py", line 636, in _update_dtr_state
OSError: [Errno 6] Device not configured
Possible causes:
- Selected Bootloader version does not match the one on Bluefruit device.
Please upgrade the Bootloader or select correct version in Tools->Bootloader.
- Baud rate must be 115200, Flow control must be off.
- Target is not in DFU mode. Ground DFU pin and RESET and release both to enter DFU mode.
A few important things:
I have nothing connected to the RESET and UserSw signal lines, and since they're pulled up in the bootloader code I believe this shouldn't matter. My understanding is the bootloader uses a control channel over USB to invoke it. Is this correct?
I have changed the boards.txt definition for this custom board to use the internal RC clock for the LFCLK source (32Khz).
My application program certainly stops when the Arduino IDE tries to connect in DFU mode.
Any movement on this issue?
bump
anything new?
Describe the bug I've been banging on the nRF52840 and having some fun with the OTA bootloader and trying to DFU my module. I have an nRF52840 Express, and also a prototype board that I spun up myself. Both boards are showing the same behavior. Since I'm debugging, I have the board connected to USB for serial coms. I have used the Bluefruit Connect app on my cell as well as the nRF Toolbox DFU tool. Both show the same behavior. It all works well, connecting and such. Then finding the file(s) for the DFU tool to use, then starting bootloader, etc., and after a minute or so I get 'Success!'. However, the board is not up. I don't see it on my Bluetooth available connections, nor do I see it on the serial port. I have tried with an open serial port in Arduino (which is nice, since it is self-healing) and I've tried without any open serial port (just plugged in to USB). Only when I reset by pressing the reset pin do I get the board to 'wake up' and it runs the new sketch from the OTA DFU it just got. This issue does not happen when I am running solely on battery power. If I'm not plugged to USB, the board (Express and my custom build) both jump right up and say 'hello' with a nice blinky LED.
Is this a bug? Or a feature?
I have not tried it with a power connection through the USB that is not a computorb. The same behavior is seen when the board has a battery or doesn't have a battery.
Set up Arduino Board Info: BN: Adafruit Feather nRF52840 Express VID: 239A PID: 8029 SN: 3BF6E9CE7B9FB5C1 Mac OS Arduino 1.8.13 to compile the sketch My custom board was bootloaded with Arduino using my Segger tool. Super easy, by the way ;)
To Reproduce I'm using the bleuart example sketch. The Bluefruit Connect or the nRF toolbox both have the same behavior after DFU.
Expected behavior The board should come out of reset and communicate over the serial port, no?