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]

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?

[Edvin]

QuentinD said:

Do you have a way to debug on a PCA10059 to see where the program crashes?

 No. Not unless you solder on a 10 pin connector on the bottom side of the dongle. 

So if you only see the lack of advertisements, then you don't know what went wrong. You only know that something isn't working.

Let me ask. Are you asking this because you only have 1x DK and 1x Dongle? If so, save yourself some time and get hold of another DK. The time you save troubleshooting must be worth more than the amount of days you have spent on this. The Dongle is not a DK for application development, but a tool to use together with nRF Connect, 802154 sniffer, nrfutil and those kind of tools. Since it doesn't have a debugger, it is very (!) hard to develop anything on/for it. 

Then, if you insist on keeping developing on the Dongle:

We don't know why it doesn't advertise. It can be a hardfault, an APP_ERROR_CHECK(err_code) or something else. 

Try to run the application with the preprocessor definition PCA10059 on your DK, and then debug it. Does the application run? Do you see anything in the log?

If you suspect the UART pins to be the issue, then you can try to ground the UART RX pin, P0.08 on the dongle. Alternatively, comment out the UART functions (at least the COMMUNICATION_ERROR event. Or you can try to simulate a floating RX pin on the DK by using a breadboard wire to pull it high and low (short it to VDD and GND) and see what happens. 

But please remember that the UART is not routed through a debugger on the Dongle, as it is on the DK, so you will not be able to use it with a terminal. The dongle's USB port is the USBD peripheral on the nRF52840, so it doesn't have any nRF -> UART -> PC functionality, unless you have an external UART -> USB device (which is usually the programmer on the DK). 

[QuentinD]

Ok so I will have to buy a debugger just to see what's wrong with the dongle.

As I said in my first post, 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  big Thread network and use my features (I don't need the UART on the dongles). I only need the dongles to do some tests to see how the Thread network behaves with my app: that's why I didn't think I would have to buy 20 PCA10056 just to do some tests ... For our customers, we will have between 20 and 100 Threads devices which will be connected to a Thread network.

Yes I have no error when I run the application on the PCA10056. But on the other hand, I notice that it doesn't work when I run it on the PCA10059.

Thank you for your recommendations: I will test that.

[Edvin]

Hello,

That was not entirely the purpose in my response. Did you try to run add a bootloader on the nRF52840 DK and run your application there? That would reveal if it is in fact a hardfault because of the bootloader or not. To make it even more similar to the dongle, do this while running the pca10059 project on the DK. Also, remember to not initialize the UART CLI when running on the dongle, unless you have actually attached those pins to a UART interface. You can simulate the error you would get on the dongle on a DK by changing the UART pin numbers to pins that aren't connected to anything, and then short the RX pin to GND and VDD a couple of times. You will see that your application will run into the COMMUNICATION_ERROR event quite rapidly, because the UART peripheral can't make sense of the "incoming UART message".

 

Edvin said:

If you suspect the UART pins to be the issue, then you can try to ground the UART RX pin, P0.08 on the dongle. Alternatively, comment out the UART functions (at least the COMMUNICATION_ERROR event. Or you can try to simulate a floating RX pin on the DK by using a breadboard wire to pull it high and low (short it to VDD and GND) and see what happens. 

But please remember that the UART is not routed through a debugger on the Dongle, as it is on the DK, so you will not be able to use it with a terminal. The dongle's USB port is the USBD peripheral on the nRF52840, so it doesn't have any nRF -> UART -> PC functionality, unless you have an external UART -> USB device (which is usually the programmer on the DK). 

[QuentinD]

Hi Edvin,

Here are the tests I performed:
- I compiled my project for pca10059 (also bootlaoder) and I executed the project on pca10056: everything works fine without errors
- I used nrf Connect to program the pca10059 with this same project (app + softdevice): I don't see my device on the nrf connect of my smartphone
- I compiled my project but by commenting the initiation of the Thread network and I run it on the pca10059: it works, I can see my device on the nrf connect of my smartphone

So there is a problem caused by the Thread part when it is executed on the pca10059.

To find out where the error is, I started by commenting out the entire Thread part and seeing if I see the device in Bluetooth: yes
Then, I uncommented line by line to see from which line I could no longer see my device in Bluetooth. Apparently, the following code is the problem in pca10059:

mp_ot_instance = otInstanceInitSingle ();
ASSERT (mp_ot_instance! = NULL);

Do you have any idea what could be causing this error?

Here is my config:
FLASH_PH_START=0x0

FLASH_PH_SIZE=0x100000

RAM_PH_START=0x20000000

RAM_PH_SIZE=0x40000

FLASH_START=0x27000

FLASH_SIZE=0xd5000

RAM_START=0x20002ae8

RAM_SIZE=0x3d518

Flash_placement.xml:

<MemorySegment name="ot_flash_data" start="0xE0000" 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 = "0xE0000" size="0x4000" />
</MemorySegment>

I used the example ble_thread_dyn_mtd_coap_cli_pca10056_s140(from nRF5_SDK_for_Thread_and_Zigbee_v4.1.0)

[Edvin]

I wasn't aware, but the bootloader on the dongle is larger than the SDK ble bootloader. It reaches from 0xE 0000 -> 0x10 0000.

I adjusted all the settings in the attached project file. I removed the build folders to keep the size small.

Try it out. It advertises as Thread_UART on my desk.

You can use the merge_app.bat file in ble_thread_dyn_mtd_coap_cli\pca10059_t\s140\ses to merge the application with the softdevice.

ble_thread_dyn_mtd_coap_cli.zip

The project you want to test is the pca10059_t\ses project.

Please note that this is not an official Nordic release. Delivered as is.

BR,

Edvin

[QuentinD]

So it was the project configuration that was problematic. Now it works

Thank you so much