• State Verified Answer
  • Replies 22 replies
  • Subscribers 73 subscribers
  • Views 7374 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 107367
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Nordic GCC HCI DFU Example hangs after 1st data packet, any idea why?

Wayne

Hi,

I'm trying to determine why a HCI DFU upload fails.
There is a log of the communication below showing the serial request/responses on the Windows side. Is anyone able to suggest what I could try to fix this or let me know what the return codes mean please?

Env:   nrf51822 AB,  SDK6.2.1,  softdevice 7.1.0  using gcc version 4.8.4 20140526

Serial config: 9600, no hw flow control

Code base: github.com/.../nrf51-dfu-bootloader-for-gcc-compiler

Modifications to bootloader: button & LED pins, clock source, serial baud set to 9600 and hw flow control disabled.

The above codebase has a windows binary, which didn't work and lacked detailed output, so instead I'm using the one from the SDK with additional print debug

I've tried with and without sending the INIT packet (the SDK6.2.1 source shows it doesn't handle it anyway) I've also added some retry loops to the serial writes.

Sending START
TX attempt #: 1
UART Write: c0 d1 4e 01 e0 03 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 a8 10 00 00 bd 83 c0
UART read: 0xc0
UART read: 0x10
UART read: 0x0
UART read: 0x0
UART read: 0xf0
UART read: 0xc0
non-slip data  [[16, 0, 0, 240]]
Ack result: 2
Sent ok!
Sending DATA
TX attempt #: 1
UART Write: c0 da 4e 20 b8 04 00 00 00 00 40 00 20 71 61 01 00 51 61 <SNIP> 4b 00 f0 8b 63 c0
UART read: 0xc0
UART read: 0x18
UART read: 0x0
UART read: 0x0
UART read: 0xe8
UART read: 0xc0
non-slip data  [[24, 0, 0, 232]]
Ack result: 3
Sent ok!
Progress:  0
TX attempt #: 1
UART Write: c0 e3 4e 20 af 04 00 00 00 71 fd a0 42 03 d0 21 1c 22 1c <SNIP> a a3 23 26 f2 c0
UART read: 0xc0
UART read: 0x20
UART read: 0x0
UART read: 0x0
UART read: 0xe0
UART read: 0xc0
non-slip data  [[32, 0, 0, 224]]
Ack result: 4
Sent ok!
Progress:  9
TX attempt#: 1
UART Write: c0 ec 4e 20 a6 04 00 00 00 db dd 00 <SNIP> c1 c0
UARt attempting read...
UARt attempting read...
UARt attempting read...
UARt attempting read...
UARt attempting read...
UARt attempting read...
UARt attempting read...
UARt attempting read...
UARt attempting read...
UARt attempting read...
Transmission timeout.
non-slip data  [[]]
Retrying packet send... err = list index out of range
TX attempt #: 2
UART Write: c0 ec 4e 20 a6 04 00 00 00 db dd 00 d0 58 <SNIP>  20 aa c1 c0
UARt attempting read...
UARt attempting read...
UARt attempting read...
UARt attempting read...
UARt attempting read...
Parents
  • 0

    This is what worked form me in the end:

    Upgraded to SoftDevice 8.0 and SDK 8.1.0

    Used keil to compile: [SDK]\examples\dfu\bootloader\pca10028\dual_bank_serial_s1107

    (I will revisit the GCC version as there was quite a bit going at the time for me, so all maybe ok)

    Upgraded nrfgo-studio from 1.18 to 1.19 (need the nrf utility which creates pacgaes from .bin and .hex files)

    Creating a pacakge and uploading:

    Add to PATH: C:\Program Files (x86)\Nordic Semiconductor\nRFgo Studio\nrf_utility

    nrf dfu genpkg app.zip --application %HEX% --application-version 0xffff --dev-revision 0xffff --dev-type 0xffff --sd-req 0x0064

    nrf dfu serial --package app.zip --port COM7 --baudrate 9600

    You may want to remove the baudrate setting, I assumed without hw flowcontrol I'd better use the lowest for testing purposes; in my case, aswell as LED and BUTTON defines I'd modifed the bootloaders hci_transport_config.h :

    HCI_SLIP_UART_MODE APP_UART_FLOW_CONTROL_DISABLED

    HCI_SLIP_UART_BAUDRATE UART_BAUDRATE_BAUDRATE_Baud9600

    USED_BAUD_RATE 9600u

Reply
  • 0

    This is what worked form me in the end:

    Upgraded to SoftDevice 8.0 and SDK 8.1.0

    Used keil to compile: [SDK]\examples\dfu\bootloader\pca10028\dual_bank_serial_s1107

    (I will revisit the GCC version as there was quite a bit going at the time for me, so all maybe ok)

    Upgraded nrfgo-studio from 1.18 to 1.19 (need the nrf utility which creates pacgaes from .bin and .hex files)

    Creating a pacakge and uploading:

    Add to PATH: C:\Program Files (x86)\Nordic Semiconductor\nRFgo Studio\nrf_utility

    nrf dfu genpkg app.zip --application %HEX% --application-version 0xffff --dev-revision 0xffff --dev-type 0xffff --sd-req 0x0064

    nrf dfu serial --package app.zip --port COM7 --baudrate 9600

    You may want to remove the baudrate setting, I assumed without hw flowcontrol I'd better use the lowest for testing purposes; in my case, aswell as LED and BUTTON defines I'd modifed the bootloaders hci_transport_config.h :

    HCI_SLIP_UART_MODE APP_UART_FLOW_CONTROL_DISABLED

    HCI_SLIP_UART_BAUDRATE UART_BAUDRATE_BAUDRATE_Baud9600

    USED_BAUD_RATE 9600u

Children
  • 0 in reply to Wayne

    @Wayne: I'm glad that you have a set up that worked. Please be aware that since you transfering the data with UART with no hardware flow control. There is a chance that the UART buffer could be full and you could have packet drop. CRC check will make sure that you have the correct image received. You would need to re-do the DFU if there is CRC mis-match. CRC check is enabled by default on SDK v8.x.

  • 0 in reply to Wayne

    thanks. it was going really well (serial upload, BLE) but then PWM wasn't working and as I started digging it came clear.. the reason is that, although SD8 is supported, unfortunately SDK 8 isn't supported on the nRF Rev 2 IC, it kinda works, but that's just fortunate, but still not supported: www.nordicsemi.com/.../41917

    What /almost/ works is SD7.1.0 + SDK8 compiled HCI DFU bootloader + SDK6.1.0 compiled application (!!). I say almost,the app runs (does BLE and PWM) but HCI DFU doesn't work, I guess it can only mean the SDK8 must be relying SD8 specific features for DFU.

    So I'm going to have to get SDK6.1.0 working... unless anyone knows anything I can do to the SDK8 HCI DFU code to make it SD7.1.0 compatible?

  • 0 in reply to Wayne

    @Wayne: The S110v8.0 is compatible with chip version 2. You can find it at table 4 in the compability document you pointed.

    The only issue is that it's not compatible out of the box. One command need to be added, please have a look at the Changes section in the S110 v8.0 release note. SDK v8.0 maybe not compatible with chip version 2 in the sense that it's not been tested with chip version 2, and may not have all the PAN fix included. You just have to make sure you applied the PAN workaround for chip version 2 in your code and you should be safe.

    Anyway, if you are planing for production, I would suggest you to continue your development on version 3 (XLR3) chip because the chips in our distributors' stock now are XLR3.

  • 0 in reply to Wayne

    thanks again, I found SD8 was ok, it's just an app built using SDK6 isn't compatible with SD8 so it fails to init the SD, hence my use of SD7. I did do a test with SD8/SDK8 having applied the 'deactivate concurrent CPU/Radio tweak', which was ok as far as I had tested... apart from PWM.

  • 0 in reply to Wayne

    @Wayne: could you give me some more information on the issue you are experiencing with PWM ?

Related
Terms of service