This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Error uploading app thru optiboot-ble and NRF toolbox

I am trying to use optiboot-ble with the nRF8001 and an atmega328p to allow application update over bluetooth. I have successfully compiled the bootloader and flashed it to the microcontroller. I have loaded the uart project with dfu from the SDK onto the microcontroller and it appears to work fine. I have been unsuccessful however in uploading an app via bluetooth using either the nRF toolbox app (ios Version 4.4.1) or the nRF Connect app (ios Version 1.7.5). Both connect fine and start the upload process but then get a disconnect error (disconnected by remote device). I have tried changing the number of packets down to 1 in the toolbox app but no change in result. Attached is the log file from the connect app.dfu log.txt

Also attached is the serial output from the debugger.debugger output.txt

  • Suggestions: Use the bootloader hex file as attached in the release in github. nRF toolbox android version (I used only the Android version):

    Settings:

    • Set the MBR size to zero
    • External MCU DFU to ON

    Additional comments, I have never used the iOS app for testing this so I suggest that the android one is use for verifying that it works.

  • Android version not working for me either with those settings. Once in the bootloader I never receive any aci events or command and so always return imediately from ble_update here: if (!lib_aci_event_get(&aci_state, &aci_data)) { return; }

    Also it appears rdyn is always high because radio never gets reset in lib_aci_init here: if (!hal_aci_tl_rdyn()) { lib_aci_radio_reset(); }

    Any idea why this would be?

    FYI I think I did find a small error in ble_optiboot with the clock division setting:

    In m_spi_init() of hal_ac_tl.c the spi control register is set as follows: SPCR |= _BV(SPE) | _BV(DORD) | _BV(MSTR) | _BV(SPI2X) | _BV(SPR0);

    SPI2X is in the SPSR register and both SPI2X and SPR0 are defined as 0 so it's redundant to include them both anyway. SPSR register should have the SPI2X bit set to to achieve div 8. As set it is div 16 which probably isn't a problem for most people.

  • You can add an issue in the github repo. You can also add a pull request for a fix. However I think we should get it working first.

    Questions: What hardware are you using ? What is the software version you are using ? Have you been able to get the ble UART project with DFU working without the DFU part ?

    • This is to verify that you have the pin information correctly setup.

    = Can you test this on an Arduino UNO board and update me ?

  • Hardware: We are doing testing with a Tinyduino tinycircuits.com/.../tinyduino-processor-board and a tinyduino ble module tinycircuits.com/.../bluetooth-low-energy-nordic-tinyshield.

    Software: We are using ble-optiboot compiled for the Atmega328P 8mhz used on that board. We have both our own code which uses the nrf8001 and the ble UART project with DFU functioning perfectly except for the DFU portion. All testing I'm currently doing is using the UART project.

    I do not have an UNO board that I can test on at this time.

    I have confirmed that once in the bootloader rdyn never goes low. If I prevent the bootloader jump - I see the following in serial debug: Jumping to bootloader E6 :6, 8C, 8, 2A, B, 0, 0, Pipe Number: 8 E3 :3, 84, F, 83, ACI Command F Evt Cmd respone: Status 83

  • David - thanks for the help - this is working now. I think I found a couple additional problems / errors under some conditions:

    1. During the watchdog reset into the bootloader rdyn and the reset lines are tri-stated. This seemed to cause problems for me locking up the nrf8001 even after I added an external pull-up on rdyn (didn't do anything with the reset). To get around this I decided to just jump from the application directly into the bootloader - rather than reset into it.
    2. In the bootloader_data_store procedure in the nordic ble sdk the following line: for (uint8_t i = 0; i < sizeof(pipes); i++) stores the incorrect number of bytes for the pipes because it is taking the sizeof the local uint8_t *pipe which is 1. This causes the ble-optiboot to read the incorrect values for the second and third pipes and thus it never progressed to the uploading of the app image stage.
Related