Issue with serial DFU on NRF52

RE: Issue with serial DFU on NRF52

Hung Bui — Thu, 20 Jul 2017 14:29:35 GMT

Hi Siva,

It's pretty strange. I just tested on my nRF52DK , I can reset the board right after programming.

Could you make it more clear what you mean LED1 changes and LED 2 LED3 glowing? What exactly was glowing, like lid up bot not solid ?

Do you see that right after you program the bootloader or when you start sending the image ?

Could you include your bootloader file and the .zip file you used ?

RE: Issue with serial DFU on NRF52

Siva — Thu, 20 Jul 2017 08:44:18 GMT

Hi Hung,

Thanks for your inputs.

I am stuck with an other issue now. I need to do a hard reset (unplug-plug the USB to serial cable in the nef52 DK) before able to perform a serial DFU. This is an intermittent issue when the softreset using SW5 isn't enough after programming the bootloader and you need to perform a hard reset to get the DFU transfer going.

I connected a saleae to trace the transfer and could see that a nrfutil is it sending a "\t 1 192" in ascii for which there is no response from the device.

The LED1 and LED3 is the one normally lit in the bootloader mode but in the instances when the device doesn't respond the LED1 changes LED2 and I can see LED2 and LED3 glowing.

The steps that I followed is as below:

Flash the SD and the bootloader after a flash erase from nrfGO.
Reset the device using SW5 and transfer the image using nrfUtil
Transfer fails with msg "No ping response" (Not always)
Unplug and plug the cable. Try the DFU now and it works.

The same happens when I switch back to the bootloader from the application for performing a DFU. The device jumps to the bootloader but the transfer fails with "No ping response"

Please let me know if you have some pointers for resolving this issue.

RE: Issue with serial DFU on NRF52

Hung Bui — Fri, 14 Jul 2017 14:45:27 GMT

Hi Siva,

If you have a look at the documentation (very first lines), you can find that the serial bootloader still require the softdevice.

The reason is that the bootloader still use the vector forwarding inside the softdevice and the flash API is also used the softdevice flash API.

The softdevice always have to be flashed first.

Erase function inside Keil is not suggested to use, the reason is that it can't erase the softdevice. You should always use nRFGo studio or nRFjprog to do flash erase.

RE: Issue with serial DFU on NRF52

Siva — Fri, 14 Jul 2017 08:52:26 GMT

So now I did a "erase all" in nRFGO, programmed the SD from it (nRFGo) and then did a full flash erase in keil and programmed the bootloader (from keil) to check the behavior. Surprisingly that too worked. In the keil debugger the address range set for the flash is 0x0 - 0x7FFFF which is the entire flash memory range of nrf52. So clearly there is something which the keil is not able to do in a full flash erase but the nrfGo can do. Because if the keil did a full flash erase like the nrfGo tool does the "erase all" then I wouldn't have got that working. In other words there is something which the nrfGo tool writes which is required by the bootloader and can't be deleted by an IDE like keil even if you try to erase the entire flash. Is there some kind of vector table which is required an inaccessible to keil? Sorry for the long comments. Let me know if you need more clarification.

RE: Issue with serial DFU on NRF52

Siva — Fri, 14 Jul 2017 08:34:29 GMT

Hi Hung, I have some interesting observations. Before coming to that, the good news is I am able to get the serial boot loader working. Until now I was using the keil to flash my serial bootloader binaries. In the "Flash Download" settings in Keil, I had opted for a full flash erase before the programming operation to simulate a bare flash scenario coming out of production. I was struggling to get the serial boot loader work with this setup.

Now I switched to nRFGo for the first time. I did the exact same procedure of "erase all" and then program the bootloader. Even this didn't seem to work. Then just my the stroke of luck I happened to program the SD after an "erase all" and then program the bootloader. Bingo, It started working now and I was able to perform serial DFU. Until then or even now I dont understand the need of the SD for bootloader to work? Continuing below..

RE: Issue with serial DFU on NRF52

Siva — Thu, 13 Jul 2017 12:57:54 GMT

Hi Hung,

I have tried with the latest version of the nrfutil-3.2 . But still its the same result. I have not done any code changes in the bootloader. I just compiled the micro-ecc and created a new publickey.c file. I am able to flash and the bootloader is waiting in the wait_for_event function. As I have mentioned, it doesn't seem to sent the full dfu packet from the host.

I am able to get the UART logs and I got most of the example applications working in my setup except this serial bootloader. Please let me know if you need any further information.

RE: Issue with serial DFU on NRF52

Hung Bui — Tue, 11 Jul 2017 14:06:38 GMT

Hi Siva,

Could you check which nrfutil version do you have make sure you have version 3.x.

You can download the latest nrfutil.exe here.

Have you modified anything on the bootloader ? If you simply test UART with a normal application does it work ?

RE: Issue with serial DFU on NRF52

Siva — Tue, 11 Jul 2017 07:37:28 GMT

Updating few more observation from the debugging done after this post:- When I put a break point on on_rx_complete in the uart_event_handler, I see that the number of bytes received is 1 and its value is 'C0' which as per Serial (HCI) should be SLIP start/stop. But I dont see the remaining bytes of the Start packet coming. I am sure DFU serial works for other so could this be an issue with the nrfUtil tool? I followed the steps in this link [link text] (infocenter.nordicsemi.com/index.jsp for its installation.