-
SoftDevice : S110 7.1
-
SDK 7.2
-
Example : nrf51-ble-app-temp + experimental_ble_app_uart
-
Using IAR 7.1
-
(Before debugging with IAR, I downloaded both the bootloader.hex and s110 7.1 hex with nrfjprog.exe)
-
Modified SDK files : bootloader_util_arm.c (copied asm code SDK 8.1 since I use ICCARM, )
-
Using nRFGo Studio 1.19.0
-
Board : PCA10001 V 2.0.0 (Rev. 2 MCU)
-
Test device : Nexus 5 (Android 5.1.1) and iPhone 6+ (iOS 8.4)
-
Toolbox App Version : 1.14.1 (at Nexus 5) & 2.1 (at iPhone 6+)
/*****************************/
Hi, I added the DFU service at the NUS example.
After I checked the firmware(NUS + DFU) starts the bootloader, the connection gets lost.
I tried to send the ble_app_hrs_dfu_s110_v7_1.hex and init file.
(The hex file and the init file or the .zip file I'm saying is the one at the app as default.)
The bootloader called static void wait_for_events(void) in bootloader.c.
However, where was a problem at checking the crc.
So what I thought was,
comparing with the HRS example that includes DFU has the bonding info.
At the link, it said that
If sharing of bond information is shared from application to DFU,
directed advertisement is used and only the bonded peer will be able to connect.
So, the HRS example bonds again with the central (such as iPhone)?
Whereas, the NUS pairs with the central, so it has to do a direct advertising, does it?
Then when I use the NUS example, shouldn't this
if (crc != m_peer_data_crc)
be not true?
I checked the thread from Stefan Birnir Sverrisson
but I don't understand why the the CRC causes the problem.
Or is it something else?
Added 18, July, 2015 : I tried the Master Control Panel (version 3.9.0, 32bit at 32bit Windows 7 SP1).
Since the DFU FAQ section G says that
Note that on MCP v3.9 we can select the hex file directly,
the .zip will be automatically generated.
so I just selected the hex file.
I tried it with the same hex file and init file using my Nexus 5 (Android 5.1.1 MCP 3.2.0).
Comparing with the HRS + DFU example, this example's DFU version is not 0.1. It is 0.5.
It failed, but the connection with the bootloader (DFUTarg) was not disconnected.
I noticed that when using the MCP Android app,
at wait_for_events(void) (bootloader.c),the loop iterates 11 times.
When using the iOS Toolbox App, it iterates only once.
Each iterations, the value of m_update_status was 0 (BOOTLOADER_UPDATING).
The firmware's program counter stays at the bootloader.
Did the log message gave enough info?
So, after showing GATT error message, the program counter is pointing the codes of the bootloader.
And when I try DFU again, it works. However, I want it the DFU to be successful in one shot.
To be more specific, I used the nrf51-ble-app-temp example.
I removed the HRS part and added
case BLE_GAP_EVT_SEC_PARAMS_REQUEST :
case BLE_GATTS_EVT_SYS_ATTR_MISSING :
case BLE_GAP_EVT_AUTH_STATUS :
case BLE_GAP_EVT_SEC_INFO_REQUEST:
at on_ble_evt function by copying the contents at the NUS example.
I also use the scheduler.
-Regards, Mango922
