Mesh DFU dfu_cmd_handler_set always failing?

RE: Mesh DFU dfu_cmd_handler_set always failing?

Hung Bui — Tue, 29 May 2018 13:16:40 GMT

Hi Andrej,

Thanks for updating us the workaround. It's a pity that it would require two machine to make a serial port working. I will talk with the team to check if they can have a better solution.

Note that even if you can't change the UART pins, you can still disconnect the UART pin to the Segger chip by cutting the SB2x solder bridge.

RE: Mesh DFU dfu_cmd_handler_set always failing?

a.wallwitz — Tue, 29 May 2018 07:56:11 GMT

I now bypassed the problem by now, just in case someone has the same problem on a Linux machine:

https://cote.cc/blog/serialproxy-v014-can-use-com-ports-above-9
Used SerProxy 0.1.4 on my Windows machine to forward the COM-Port to TCP/IP

Connected on my Linux machine the TCP/IP to a virtual modem:
sudo socat pty,link=/dev/vmodem0,raw tcp:x.x.x.x:xxxx

Then used nrfutil for mesh with the virtual modem as serial interface.

--> Working

But this is just a workaround. Please solve this issue as I need two machines for this and it might not be that reliable.

I hope this will help some people.

Bye
Andrej

P.S.: If someone has the same problem it might be also possible to forward the USB device (DevKit) to a Windows VM that is then in a private network with the host. Not confirmed but should work. Using this method you would one have to use one physical machine. Could not test it due to license issues (no additional corporate Windows license)

RE: Mesh DFU dfu_cmd_handler_set always failing?

a.wallwitz — Thu, 24 May 2018 12:34:59 GMT

Hi Hung,

changing the pins for the bootloader will be hard without the source code. 😞

The serial communication was not working all the time at the training. Once it worked we kept everything open and running. Once we disconnected something and tried to use it again we had the timeout issue again. Remember?

Bye
Andrej

RE: Mesh DFU dfu_cmd_handler_set always failing?

Hung Bui — Thu, 24 May 2018 12:22:00 GMT

Hi Andrej,

If you have your own UART port on your PC you don't have to use the SEGGER one. Just configure the firmware on the chip to use different UART pin and use those pins to connect to your USB-UART.

As far as I remember the communication were quite stable when we were at the training ?

RE: Mesh DFU dfu_cmd_handler_set always failing?

a.wallwitz — Thu, 24 May 2018 11:38:03 GMT

Hi Hung,

this solution is working. Thanks for that.
But I still have a massiv problem with the serial communication using SEGGER 6.16c on my linux machine. 😞

It looks like this communication is only working by chance as it is almost always working on my windows machine.

Is there a way to replace everything SEGGER<->UART related by external USB<->UART?

Bye
Andrej

RE: Mesh DFU dfu_cmd_handler_set always failing?

Hung Bui — Thu, 24 May 2018 08:24:36 GMT

Hi Andrej,

Did you use SES to build the DFU project ?

If you did, could you try a quick patch to see if it fixes the issue for you? R&D told me about the bug that SES-built firmware will clear the RAM part of the bootloader and cause the CMD handler location to be NULL.

In examples/dfu/flash_placement.xml, change line 32 from

Please let me know if it fixes the issue.

RE: Mesh DFU dfu_cmd_handler_set always failing?

a.wallwitz — Wed, 23 May 2018 08:51:36 GMT

Hi Hung,

so I redownloaded the Mesh SDK2.0.1 and compiled the DFU-App-example (just to be sure that I did not mess up something)

I rebuilded the device page and flashed everything (Softdevice 6.0.0, Bootloader (gccarmemb_serial_nrf52832_xxAA), device_page and dfu_app - in that order). Then the reset of the board and the example boots.

But I still get this "No CMD handler!" ERROR from nrf_mesh_dfu.c line 901.

Looks like the bootloader is not compatible with softdevice 6.0.0 or it is broken to me?

Could you please verify that this guide (except for replacing "sd_5.0.0" by "sd_6.0.0"): http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.meshsdk.v2.0.1/md_doc_getting_started_dfu_quick_start.html
Is still vaild for SDK 2.0.1 including all files included in SDK 2.0.1? Like bootloader, device_page_generator etc.?

FYI: I get the exact same error on my windows machine as it is not a serial issue but a "memory-address-to-ram-write"-issue within the bootloader as far as we can tell now, I guess.

Thank you for your help and I hope to hear from you soon once this is verified 🙂

______

Andrej

RE: Mesh DFU dfu_cmd_handler_set always failing?

Hung Bui — Tue, 22 May 2018 16:32:33 GMT

Hi Andrej,

My understanding is that the bootloader should write the address of the dfu_cmd_handler (that is located inside the bootloader) in to the last address in RAM. dfu_cmd_handler_set() will check if the address is located inside bootloader flash area or not. I'm not sure how in your case it ends up in the application.

Do you have the same problem when you test on Windows machine ? Have you managed to perform any DFU update using Windows ? If you do, we can focus on the incompatibility on Linux. I will try to get the team to have a look on the issue.

RE: Mesh DFU dfu_cmd_handler_set always failing?

a.wallwitz — Tue, 22 May 2018 09:11:38 GMT

https://devzone.nordicsemi.com/f/nordic-q-a/34378/mesh-dfu-example-not-working-no-serial-communication-for-linux-and-more

Check the first part of the ticket. This is how I fixed this problem you have ;)

RE: Mesh DFU dfu_cmd_handler_set always failing?

Giang — Tue, 22 May 2018 07:26:49 GMT

Hi , I'm also running that example . But I follow : http://infocenter.nordicsemi.com/index.jsp . When I run to step 4 :

dfu$ python device_page_generator.py -d nrf52832_xxAA -sd "s132_5.0.0"

I get this error :

Did you encounter this error? If yes, can you give me the solution. Thank!!!

RE: Mesh DFU dfu_cmd_handler_set always failing?

a.wallwitz — Tue, 22 May 2018 07:19:34 GMT

Short update:
The handler-address seems to be
handler = 0x2618F which is inside the application, not in the bootloader.

Unfortunately the bootloader is not available as source to check what is placed at RAM when 😞