• State Verified Answer
  • Replies 22 replies
  • Subscribers 73 subscribers
  • Views 7391 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...
  • 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 ?

  • 0 in reply to Wayne

    SImply put, there is no PWM output. When porting from SDK6 to SDK8 I made some minor mods to the SDK6 based code base where the SDK8 had made some function name changes,e.g. nrf_gpiote_task_config becomes nrf_gpiote_task_configure . So the current code I have is not using the new SDK8 abstractions. The code base has PAN 26and PAN 59 applied.

Related
Terms of service