Peripheral fault from DLE with s132 v3.0?

RE: Peripheral fault from DLE with s132 v3.0?

Petter Myhre — Tue, 23 May 2017 07:23:29 GMT

@KV I don't have that. I think you should add a new question and link to this one if it is relevant.

RE: Peripheral fault from DLE with s132 v3.0?

KV — Mon, 22 May 2017 18:46:46 GMT

Do you have a similar example for S140 and nRF52840?

I tried to mimic this for S140 but the ble_peripheral does not advertise (LED1 does not blink) and when I stop the debugger it is at some unknown memory address (0x99d8)

RE: Peripheral fault from DLE with s132 v3.0?

xeem — Tue, 28 Mar 2017 05:04:40 GMT

edit problem resolved. Please ignore!

RE: Peripheral fault from DLE with s132 v3.0?

Petter Myhre — Mon, 06 Mar 2017 16:45:20 GMT

I guess because the peer doesn't send ATT Exchange MTU Request?

RE: Peripheral fault from DLE with s132 v3.0?

User1321 — Mon, 06 Mar 2017 16:13:27 GMT

No! I am never getting that! Any idea why?

RE: Peripheral fault from DLE with s132 v3.0?

Petter Myhre — Mon, 06 Mar 2017 11:25:23 GMT

Are you getting the BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST and BLE_EVT_DATA_LENGTH_CHANGED events? They are handled inside on_ble_evt().

RE: Peripheral fault from DLE with s132 v3.0?

User1321 — Fri, 03 Mar 2017 10:37:14 GMT

No, I am using the armgcc and I need to make some changes on the makefile in order to make it compile. On the makefile it appears: $(PROJ_DIR)/../../bsp/bsp.c
$(PROJ_DIR)/../../bsp/bsp_btn_ble.c
.... $(PROJ_DIR)/../../bsp
and those are not properly located, I change it to those that appear on the sdk12.2 libraries directory. It can also not find this folder: $(PROJ_DIR)/config/ble_app_uart_pca10040_s132 \ If deleted from the makefile it and make the previous changes it compiles.

RE: Peripheral fault from DLE with s132 v3.0?

Petter Myhre — Fri, 03 Mar 2017 10:29:18 GMT

Do the unmodifed examples work together?

RE: Peripheral fault from DLE with s132 v3.0?

User1321 — Fri, 03 Mar 2017 10:09:09 GMT

Thanks Petter, I could download it fine now. However, it still does not send more than 20 bytes. I have copied and linked to my project: main.c, ble_nus.c, ble_nus.h, config file: sdk_config.h. I also replaced the softdevice_handler folder on the /...components/softdevice/common directory. I know that the problem is not on the central program because it works find on other project receiving more than 20bytes. Any idea of can I be missing? Thanks in advance.

RE: Peripheral fault from DLE with s132 v3.0?

Petter Myhre — Thu, 02 Mar 2017 20:12:15 GMT

Strange, works fine to unzip here. I uploaded a zip in addition to the rar, you can try to that.

RE: Peripheral fault from DLE with s132 v3.0?

User1321 — Thu, 02 Mar 2017 17:56:19 GMT

I can download fine the example but when I try to extract it (unzip) it says that there is an error and some files are lost, I created the uart peripheral project by myself based on the .c and .h files that were successfully downloaded, in the case of the central I use the hex file. It compiles ok and sends short messages properly but when I try to send more than 20 bytes it ignores it and it just sends the first 20 bytes. Any idea what could be wrong? can you update the file so It can be extracted without errors?

RE: Peripheral fault from DLE with s132 v3.0?

Petter Myhre — Mon, 07 Nov 2016 11:19:32 GMT

Great! You could also use a debugger and check the value.

RE: Peripheral fault from DLE with s132 v3.0?

Martin Roa Villescas — Mon, 07 Nov 2016 11:17:27 GMT

@Petter Thanks for the re-explanation. I was able to finally overcome the NRF_ERROR_NO_MEM error. Indeed it is the ICFEDIT_region_RAM_start value in the linker configuration file (ble_app_uart_c_iar_nRF5x.icf) that you have to modify according to what the NRF_LOG_WARNING says. My main problem is that the NRF_LOG_WARNING does not work together with the NUS service since I guess that they both try to claim the UART (in uart_init() and in NRF_LOG_INIT(NULL)). My solution was to temporarily comment out the NUS UART related code in order to see the NRF_LOG warnings. I'm sure there must be a better way to do this.

RE: Peripheral fault from DLE with s132 v3.0?

Petter Myhre — Mon, 07 Nov 2016 10:04:34 GMT

I'm not sure what you don't understand, have you examined softdevice_enable()? I'll try to rephrase. In softdevice_enable() ram_start equals the linker value of the RAM starting point of the application. app_ram_base is set to ram_start and is given to the SoftDevice through sd_ble_enable(), together with its configuration, where you set the maximum size of ATT MTU, number of links, and so on.

The SoftDevice will compare the value of app_ram_base with the RAM it actually needs, if not enough RAM is provided sd_ble_enable() will return NRF_ERROR_NO_MEM and app_ram_base will will be the required RAM starting point of the application.

RE: Peripheral fault from DLE with s132 v3.0?

Martin Roa Villescas — Mon, 07 Nov 2016 09:16:51 GMT

@Petter Could you please rephrase the second part of your comment? I don't think I understand:

ram_start is the current starting point for the application, while app_ram_base is the required starting point for the application (after the call to sd_ble_enable())

On the other hand, the first part is clear: If you increase the MTU size then you have to increase the amount of RAM reserved for the SoftDevice. However, I still don't know where exactly you can increase the amount of RAM for the SoftDevice. Is it in the linker configuration file? Somewhere else? If we want to have an MTU size of 247 instead of 158, does that mean that we have to increase the SoftDevice RAM size by 89 bytes? Thanks in advance.

RE: Peripheral fault from DLE with s132 v3.0?

Petter Myhre — Wed, 28 Sep 2016 10:34:33 GMT

@Eugene It is returned from sd_ble_enable(), and 0x0004 is NRF_ERROR_NO_MEM. If you increase the MTU the SoftDevice will require more RAM. Examine softdevice_enable(). ram_start is the current starting point for the application, while app_ram_base is the required starting point for the application (after the call to sd_ble_enable()).

RE: Peripheral fault from DLE with s132 v3.0?

Eugene — Wed, 28 Sep 2016 10:25:02 GMT

Why is NRF_BLE_MAX_MTU_SIZE restricted by 158 bytes value? When i change it to 247 it failures with code 4 during soft device activation. What causes it?

RE: Peripheral fault from DLE with s132 v3.0?

Elias — Tue, 20 Sep 2016 07:04:36 GMT

I haven't managed to go through the example completely, but making the modification to ble_stack_handler_types.h allowed me to double packet size and increase application throughput by about 100kb/s immediately, so I'll consider my issue resolved for now.

RE: Peripheral fault from DLE with s132 v3.0?

eyeye — Tue, 20 Sep 2016 03:32:50 GMT

Hi @Petter, I have try your examples on two nRF52-DK. It works as expected, the ATT_MTU and LL Data length extended. When I replace the central nRF52-DK with my iPhone6(iOS10), only ATT_MTU exchanged, LL Data length doesn't extended. nRF52 response the LL_LENGTH_REQ cmd with LL_UNKNOWN_RSP. It should be LL_LENGTH_RSP.

from this question you can get more detail information.

RE: Peripheral fault from DLE with s132 v3.0?

Petter Myhre — Mon, 19 Sep 2016 15:01:35 GMT

Here are examples of ATT MTU exchange and DLE.

I modified ble_app_uart and ble_app_uart_c. You should be able to send up to 155 bytes of data in one packet.

Use two terminals to send and receive data.

Here is a ZIP.

RE: Peripheral fault from DLE with s132 v3.0?

Petter Myhre — Fri, 16 Sep 2016 16:27:07 GMT

I will look into this first thing Monday.