Hardfault error in porting Thead example (with SoftDevice) from PCA10056 to PCA10059

[QuentinD]

Hello,

I notice that Thread examples with Softdevice (nRF5_SDK_for_Thread_and_Zigbee_v4.0.0_dc7186b) works fine for a PCA10056 but not on a PCA10059.

When I had tried to make this exemples works for a PCA10059 (following the instructions given here "https://devzone.nordicsemi.com/nordic/short-range-guides/b/getting-started/posts/nrf52840-dongle-programming-tutorial" - replace BOARD_PCA10056 to BOARD_PCA10059 in preprocessor definitions), it never worked: once the device programmed (with nRF Connect), nothing happened.

Jørgen Holmefjord  confirmed me that there are a problem... This was his reply (ticket at devzone.nordicsemi.com/.../porting-ble_thread_dyn_mtd_coap_cli-from-pca10056-to-pca10059):
"I did a test with the latest SDK version, by changing BOARDS_PCA10056 to BOARDS_PCA10059, but I'm not able to run it on the dongle. It seems to run fine on the nRF52840 DK however. I think this is related to the lack of a UART port on the dongle, and/or GPIO config for LEDs and button(s). I will try to make a working version of the application for the dongle.

...

I did some more testing on this today, but it seems I always get a Hardfault in softdevice area when the OpenThread libraries are initialized on the Dongle. I did manage to run the application on a dongle that I erased and programmed through the debug-header, but I cannot get it to work with the bootloader present. I would highly recommend you to get a DK to do the development on, as the dongle does not provide good debug-capabilities."

In fact, when I comment out the Thread part in the example "ble_thread_dyn_mtd_coap_cli_pca10056_s140", the program runs correctly in a pca10059. However, if the OpenThread is  enabled, this example does not work on the pca10059.

For your information, I had to modify the flash_placement.xml file so that the "start_ot_flash_data" address is 0xE0000 instead of 0xFC000 (because if I use this example with the bootloader (the bootloader is between the addresses 0xE4000 to 0xFE000), the Thread and the bootlaoder use the same addresses). Doing this allows you to run this example with the bootloader on a pca10056 but does not yet solve the problem for a pca10059.

I have 3 DK boards and 20 dongles. My application was completely developed on the DK but I would like to incorporate it into the dongles to simulate a Thread network and use my features (I don't need the UART on the dongles). So that's why I need to be able to operate the dongle with my app.

Could you look at why there is a problem when using this example in a pca10059?

Thank you

[Vidar Berg]

Hello,

The bootloader starts at 0xE0000 if you use the original one that comes pre-programmed on the dongle? In that case, you need to set the OT flash section start address to 0xdc000, same as in the  \examples\thread\cli\ftd\usb\pca10059\ project.

  <MemorySegment name="ot_flash_data" start="0xdc000" size="0x4000">
    <ProgramSection alignment="4" keep="Yes" load="Yes" name=".ot_flash_data" address_symbol="__start_ot_flash_data" end_symbol="__stop_ot_flash_data" start = "0xdc000" size="0x4000" />
  </MemorySegment>

[QuentinD]

Hello,

I tried the change of address you are proposing, but unfortunately that does not correct the problem ...

Can you try to generate an example located in the folder "examples \ multiprotocol \ ble_thread" to make it PCA10059 compatible?

Thank you

[Edvin]

Hello,

Vidar is out of office, so I will handle this case. 

I guess you are also trying to upload this with nRF Connect -> Programmer, since you are trying to run it on an nRF52840 Dongle?

If so, you also need to make space for the MBR in the start of the RAM. Please try to follow this guide:

https://devzone.nordicsemi.com/tutorials/b/getting-started/posts/nrf52840-dongle-programming-tutorial

You should also define "MBR_PRESENT" in your preprocessor definitions, and then add the .h files that the application project asks for when this is done:

Add <SDK_ROOT>\components\softdevice\mbr\headers to your include directories.

I looked at something similar once, but it was a private ticket, so it is not possible to link to it, but we created this port:

simple_coap_client.zip

Where the pca10056\blank\ses project is ported to the dongle.

Perhaps you can compare it to your project, and see what changes you are missing.

If you have done this, and it still doesn't work, please let me know.

BR,

Edvin

[QuentinD]

Hi Edvin,

I followed this guide well but it still does not work ... As a reminder, I only have this problem on the examples using the SoftDevice (it works well when there is no softdevice).
In the example you gave me, there is no softdevice so it works without problem for me too.

Could you try to convert to PCA10059 an example found in the folder "... \ examples \ multiprotocol \ ble_thread" ("thread_simple_coap_client_pca10056" for example as is the example I use)? Jørgen Holmefjord said he get a Hardfault in softdevice area when the OpenThread libraries are initialized on the Dongle but having no external debugger, I cannot confirm it.

Thank you

[Edvin]

The thread_simple_coap_client_pca10056 is not in the multiprotocol\ble_thread folder. I will try with the ble_thread_dyn_proximity example.

You can try to run the project on the DK even though you change to PCA10059. It will run even though the LEDs will not be on the correct pins. 

I tried to run it on a DK first, and it ran as expected. Then I tried to add a serial bootloader, since that is similar to what the dongle uses, and then I ran into a hardfault. I tested on SDKv 4.1.0 as well, and there it ran without the hardfault. Can you port to SDK4.1.0 and use that? Even if we find the bug, it will not be fixed in the 4.0.0 version. All I needed to do is to change the pca10056 to 10059 define. 

I didn't test extensially, but I saw that it didn't run into a hardfault immediately. I didn't try to make it join a network. Can you try the same, and change the Memory segments in the SES settings as well. You probably need that in order to use the network features.

If you run into any other issues, please try to debug them on a DK. We are very low on staffing this month, so replies can be slow.

Best regards,

Edvin

[QuentinD]

Sorry, I made a bad copy-paste ... I use the example "ble_thread_dyn_mtd_coap_cli_pca10056_s140".

As I have said several times, this example works well on the PCA10056 ... If I change only BOARDS_PCA10056 to BOARDS_PCA10059 in preprocessor definitions, the example works well on the PCA10056 (without bootloader). If I want to run this example with the bootlaoder, I need to modify the flash_placement.xml file so that the "start_ot_flash_data" address is 0xE0000 instead of 0xFC000 (because if I use this example with the bootloader (the bootloader is between the addresses 0xE4000 to 0xFE000), the Thread and the bootlaoder use the same addresses). Doing this allows you to run this example with the bootloader on a pca10056 without hardfault. But it is not enough for it to work on the PCA10059 ... As Jørgen Holmefjord said, he think this is related to the lack of a UART port on the dongle, and/or GPIO config for LEDs and button(s).

So could you please run this code on a PCA10059? You will see that there is a problem ...

Thank you

[Edvin]

QuentinD said:

Sorry, I made a bad copy-paste ... I use the example "ble_thread_dyn_mtd_coap_cli_pca10056_s140".

 No worries

I checked the hardfault that I got. It was inside the softdevice, and related to a flash erase page operation, which points towards the bootloader. 

I am not familiar with all the changes between SDK4.0.0 and 4.1.0. But can you please test on SDK4.1.0? At least in my case, this made the hardfault go away, so perhaps the OpenThread stack has a new (correct) way of checking whether there is a bootloader present or not.

BR,

Edvin

[QuentinD]

Here is the test I just performed:
- I downloaded the SDK "nRF5_SDK_for_Thread_and_Zigbee_v4.1.0_32ce5f8"
- I have changed BOARDS_PCA10056 to BOARDS_PCA10059 in preprocessor definitions (in ble_thread_dyn_mtd_coap_cli_pca10056_s140 example)
- I have modified the flash_placement.xml file so that the "start_ot_flash_data" address is 0xE0000 instead of 0xFC000
- I have compiled the bootloader (debug) for the PCA10059
- I have merged bootloader, SoftDevice, Appli and boot settings
- I have programmed the PCA10056 with the full hex: it works correctly
- I have programmed the PCA10059 (only with the app and the softdevice): it doesn't work

To find out if it works, I use "nRF Connect" to see if I see the device in Bluetooth.

I think the hardfault of the OpenThread stack comes from the address which is used by default in the bootloader. So changing the address of "start_ot_flash_data" corrects the problem for pca10056.
But for the pca10059, I wonder if it is not because the uart is used in this example while the pins are not connected on the pca10059? Do you have a way to debug on a PCA10059 to see where the program crashes?