Error uploading app thru optiboot-ble and NRF toolbox

RE: Error uploading app thru optiboot-ble and NRF toolbox

dlip — Wed, 07 Jun 2017 22:48:42 GMT

If you want me to I can add the issues in the github repos if it is helpful.

RE: Error uploading app thru optiboot-ble and NRF toolbox

dlip — Wed, 07 Jun 2017 22:20:11 GMT

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

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.
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.

RE: Error uploading app thru optiboot-ble and NRF toolbox

dlip — Fri, 02 Jun 2017 11:55:10 GMT

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

RE: Error uploading app thru optiboot-ble and NRF toolbox

David Edwin — Fri, 02 Jun 2017 08:29:30 GMT

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 ?

RE: Error uploading app thru optiboot-ble and NRF toolbox

dlip — Thu, 01 Jun 2017 19:52:10 GMT

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:

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.

RE: Error uploading app thru optiboot-ble and NRF toolbox

David Edwin — Thu, 01 Jun 2017 12:07:40 GMT

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.