MTU size change then infinite reboot

RE: MTU size change then infinite reboot

Petter Myhre — Wed, 31 Jan 2018 14:29:51 GMT

SoftDevice S132 v3, supported by SDK 12, is the first to support configurable ATT MTU. There is is called NRF_BLE_GATT_MAX_MTU_SIZE. In SDK 14 it is called NRF_SDH_BLE_GATT_MAX_MTU_SIZE

RE: MTU size change then infinite reboot

Alaa — Wed, 31 Jan 2018 14:19:13 GMT

Can you tell me what's the minimum version that supports configurable ATT MTU? I can't find the macro also in SDK 14. Where should it be located at? Thanks

RE: MTU size change then infinite reboot

Petter Myhre — Wed, 31 Jan 2018 12:01:24 GMT

No, not really.

RE: MTU size change then infinite reboot

Alaa — Wed, 31 Jan 2018 11:48:05 GMT

Thanks. Is there a guide how to migrate from 11 to 14? I found guides migrating from 12 to 13 and from 13 to 14

RE: MTU size change then infinite reboot

Petter Myhre — Wed, 31 Jan 2018 11:46:18 GMT

SDK 11 uses SoftDevice S13x v2, this does not support configurable ATT MTU.

RE: MTU size change then infinite reboot

Alaa — Wed, 31 Jan 2018 11:35:41 GMT

SDK 11, example ble_app_uart

RE: MTU size change then infinite reboot

Petter Myhre — Wed, 31 Jan 2018 11:34:02 GMT

Which SDK version are you using? Which example?

RE: MTU size change then infinite reboot

Alaa — Wed, 31 Jan 2018 11:31:27 GMT

Where is this NRF_BLE_MAX_MTU_SIZE? I can only find GATT_MTU_SIZE_DEFAULT and GATT_RX_MTU

RE: MTU size change then infinite reboot

Petter Myhre — Thu, 02 Feb 2017 19:48:21 GMT

That define is incorrect, see this on how to achieve the highest throughput. If you have more questions I really think you should add them separately. This is getting very cluttered.

RE: MTU size change then infinite reboot

minswho — Thu, 02 Feb 2017 17:39:26 GMT

I realized that my serial monitor was connected to the other nrf chip that wasn't flashed with new ram start address yet.

I increased the RAM start address and corresponding size with r1 values from both central and peripheral sketch and it seems to be working fine.

But could you tell me what the maximum MTU size is for the current SDK? I'm getting contradicting information from various sources.

This is my current definition.

#define NRF_BLE_MAX_MTU_SIZE    103

RE: MTU size change then infinite reboot

minswho — Thu, 02 Feb 2017 17:10:43 GMT

I tried changing the address to r1 value and increased the size correspondingly but CTS light is keep blinking and I believe going through an infinite loop. Please advise. Thank you.

RE: MTU size change then infinite reboot

minswho — Thu, 02 Feb 2017 16:58:50 GMT

I confirmed that disabled optimization setting wasn't saved and changed it back to level 0.

However, I am still not seeing any value when I hover over the variable. I even put them on watch and their values return ""

I haven't had a chance to read through the assembly yet but is r1 value just the start address value?

http://imgur.com/a/HE2DB

RE: MTU size change then infinite reboot

Petter Myhre — Wed, 01 Feb 2017 17:33:52 GMT

Great. It doesn't look like you have turned off optimizations. You should have several places to put a breakpoint after sd_ble_enable() is called. Then it is simple to hold your mouse pointer on the app_ram_base value to see its value. You turn off optimizations by going into Options for Target->C/C++->Optimization Level 0

RE: MTU size change then infinite reboot

minswho — Tue, 31 Jan 2017 22:56:21 GMT

I was actually able to find the app_ram_base variable. http://i.imgur.com/gNXto90.png

However, I'm not really familiar with Keil and can't figure out how to output the variable value. What would be the easiest way to do that?

RE: MTU size change then infinite reboot

minswho — Tue, 31 Jan 2017 19:56:41 GMT

I even ran a search for sd_ble_enable() for the whole project but I was only able to find two comments that said something along the lines of "Calling @ref sd_ble_enable() with *p_app_ram_base set to 0 can be used during

development to find out how much memory a specific configuration will need."

Looking up the function in the SDK documentation didn't really help either.

Would you mind giving me more information or detailed instruction? I'm using nRF5_SDK 12.2.0 S132 UART central and peripheral example.

RE: MTU size change then infinite reboot

minswho — Tue, 31 Jan 2017 18:34:53 GMT

I turned off optimizations (level 0) and recompiled. However, I'm having some trouble finding the softdevice_enable. Could you elaborate what you mean by "go into" it?

If it's a class file, I can't seem to find it inside any of the project directories.

Thank you.

RE: MTU size change then infinite reboot

Petter Myhre — Tue, 31 Jan 2017 11:05:42 GMT

Of course. First turn off optimizations and recompile. Then go into softdevice_enable, there you see a function named sd_ble_enable(). If you put a breakpoint after this function is called you can check the value of app_ram_base to see what the RAM start address should be. The size should be 0x10000 - app_ram_base = size.

RE: MTU size change then infinite reboot

minswho — Mon, 30 Jan 2017 21:15:01 GMT

I'm just having a hard time finding the RAM start address you were talking about. Would you mind helping me with just that? I don't think a separate thread is necessary.

This is what I'm currently seeing from the debugger. https://goo.gl/YGrZS0

RE: MTU size change then infinite reboot

Petter Myhre — Mon, 30 Jan 2017 12:50:37 GMT

I guess my answer below was the solution, since he accepted it. If that doesn't solve you problem I recommend adding a new question with your setup.

RE: MTU size change then infinite reboot

minswho — Fri, 27 Jan 2017 22:06:39 GMT

I'm having the same problem. Did you ever figure out the solution?

RE: MTU size change then infinite reboot

Petter Myhre — Tue, 20 Dec 2016 11:57:14 GMT

It is probably returned from sd_ble_enable(). It means that you haven't provided enough RAM for the SoftDevice, because you increased the ATT MTU.

Examine softdevice_enable(), app_ram_base will tell you the required RAM start address for the application. Print it, or check it with the debugger (turn off optimizations).