Wireless programming Arduino with nrf8001

[Stickables]

We're building a low cost device with an nRF8001 as the only means of communication as physical access is closed after the device is built.

Is there any way to change the nRF8001 output mode to stream data directly to the micro so we can program it wirelessly, for firmware updates? Supporting electronics can be added and the dedicated pins on the micro will be available.

[Stickables]

Thank you for the sniff trace, I'll try to do one as soon as I have the PCA10000 with me again.

In the meantime, I've done some more tests and found that the only way I could get to "Transmitting application" was when I had a faulty reset wire on my custom board. With that fixed, the result is the same as the one replicated on a bare Arduino with Adafruit breakout: DFU process starts, application on MCU jumps to bootloader but after a few seconds it disconnects, and the application starts again.

I have still don't know what could be stopping the DFU process from working, seeing as you are able to do with virtually the same hardware. All the fuses are the same, I've ensured the bootloader is correctly flashed by dumping it and md5, the pinout is the same. I'm using the example files provided straight out of the BLE-SDK downloaded from github.com/.../ble-sdk-arduino .

I have also tried the ble_proximity_with_dfu_template and the Android app tells me "GATT ERROR" in the DFU process.

[David Edwin]

Can you try it on an Arduino UNO board ? How are you flashing the bootloader (JTAGICE3) ? Make sure that the EEPROM and Flash are cleared before programming.

[Stickables]

I have tried with a Arduino UNO, programmed using a USBASP; also tried on the custom board using ArduinoISP R3. Both the EEPROM and Flash are auto-erased before flashing. The result is the same: failure to connect to bootloader. Could the programmer make any difference? I've dumped the bootloader after flashing and it checks out 100%.

[David Edwin]

I see that the Atmel studio/JTAGICE3 is doing an "Auto read" of the fuses, so I am only adding the bits to increase the size, and also following the recommendation in the README for the optiboot. Used www.engbedded.com/fusecalc to see which bits need to be turned on in addition i.e. BOOTSZ0, BOOTSZ1 and BOOTRST.

So if you started from a working Arduino UNO bootloader that would be easier.

I do not have access to a USBASP so I do not think I can test using that.

[Stickables]

That's exactly what I did, started from the default Uno fuses and modified according to the README, which gives out Low FF, High D0, Extended FF (or 0x07, as only the last 3 bits are used). I've tried every start-up time combination for low-fuse, using external 16 MHz crystal, like the Uno, behaviour is always the same. High fuses are the same as yours, only option is to whether preserve the EEPROM or not on flash (I have it to preserve, as you do). Extended fuses only deal with brown-out so it shouldn't affect the outcome.