Problem with custom DFU Buttonless app (bootloader + settings + app .hex with bond_forwarding doesn't run)

RE: Problem with custom DFU Buttonless app (bootloader + settings + app .hex with bond_forwarding doesn't run)

Bruno Santamaria — Wed, 13 May 2020 08:49:01 GMT

Hi, that was it!

Of course, the reset pin! I removed the CONFIG_GPIO_AS_PINRESET months ago at the beggining of the development. What I didn't expect is that, if the bootloader has that flag, the pin is still used for reset in the app.

Now I applied the same configuration of my app to the bootloader and my button on P0.21 works again.

Thanks Vidar Berg!

RE: Problem with custom DFU Buttonless app (bootloader + settings + app .hex with bond_forwarding doesn't run)

Vidar Berg — Wed, 13 May 2020 07:49:53 GMT

Hi,

The reset pin (P0.21) is enabled by default in all of our SDK examples by including the CONFIG_GPIO_AS_PINRESET flag in the preprocessor definitions. So it must be removed if you are using P0.21 as a regular GPIO.

Note that the pin reset setting is stored in the non-volatile UICR section, so you will need to perform an ERASEALL or UICRERASE to clear this setting.

RE: Problem with custom DFU Buttonless app (bootloader + settings + app .hex with bond_forwarding doesn't run)

Bruno Santamaria — Tue, 12 May 2020 07:51:45 GMT

Hi Vidar Berg,

[quote userid="4240" url="~/f/nordic-q-a/60994/problem-with-custom-dfu-buttonless-app-bootloader-settings-app-hex-with-bond_forwarding-doesn-t-run/248891"]The best solution is to allocate a fixed portion of RAM to rtt as explained in the forum thread you linked to. But it requires some work, and the approach will differ depending on toolchain type.[/quote]

For now I'm trying to avoid doing this, especially since my bootloader is not logging.

[quote userid="4240" url="~/f/nordic-q-a/60994/problem-with-custom-dfu-buttonless-app-bootloader-settings-app-hex-with-bond_forwarding-doesn-t-run/248891"]Does it fail consistently and do you see any pattern? E.g., does not work after power-cycle, etc.[/quote]

What I've tried is to divide my last commits into two branches, one for DFU and one for encryption/pairing/fds. This way I can tell apart what is not working.

What I see is that from my three buttons - all of which work fluently using only SD + App, now only two still work. When using SD + DFU + APP or SD + DFU + DFU_Buttonless_App, when I press my button my app resets. It seems like the bootloader is using that same pin for reset, but I haven't found any information on that regard.

That button is on PIN 21 as defined in my custom_board.h file.

For now the rest of my app seems to work as before. How can I solve the problem with that button?

Thanks in advance.

RE: Problem with custom DFU Buttonless app (bootloader + settings + app .hex with bond_forwarding doesn't run)

Vidar Berg — Fri, 08 May 2020 10:19:39 GMT

Hi Bruno,

[quote user="bruno_san"]If this is so, what do you mean by "disable RTT logging in the bootloader"? Do you mean that I should connect with Segger RTT to my device only when I'm sure the application is running and closing it before it changes to bootloader?[/quote]

I assumed you were using the bootloader with logging. I didn't know it could become a problem without. Does it fail consistently and do you see any pattern? E.g., does not work after power-cycle, etc.

The best solution is to allocate a fixed portion of RAM to rtt as explained in the forum thread you linked to. But it requires some work, and the approach will differ depending on toolchain type.

Regards,

Vidar

RE: Problem with custom DFU Buttonless app (bootloader + settings + app .hex with bond_forwarding doesn't run)

Bruno Santamaria — Thu, 07 May 2020 12:54:50 GMT

Hi Vidar Berg, thanks. I think I understand what you mean. Just to be clear, does this RAM address get moved when changing from Bootloader to Application even though my Bootloader is not writing debug messages nor even using nRF_Log? (I didn't use the "_debug" example).

If this is so, what do you mean by "disable RTT logging in the bootloader"? Do you mean that I should connect with Segger RTT to my device only when I'm sure the application is running and closing it before it changes to bootloader?

Especially if the answer to the previous cuestion is that is not enough to use RTT just taking care that only the application is running, how can I link the RTT block to a fixed RAM position? I haven't found any documentation but this post from a regular user.

Regards,

Bruno

RE: Problem with custom DFU Buttonless app (bootloader + settings + app .hex with bond_forwarding doesn't run)

Vidar Berg — Wed, 06 May 2020 11:14:52 GMT

Hi Bruno,

I recommend going with the unbonded variant without bond sharing if you don't have a requirement to have a secured link during the DFU transfer. It less complicated and there's is less things that can go wrong with it. This does not have any impact on bonding support in the main app.

[quote user=""]App seems to work but seems not to be stable. Sometimes NUS service doesn't seem to work (RTT doesn't show messages and I get no reply), other times it does, not all Debug data appears on RTT, on some ISR of my buttons, app seems to freeze. None of these happened before adding DFU[/quote]

This is a known limitation when working with the bootloader. RTT keeps log messages in a RAM buffer which the debugger locates by scanning the RAM area on connection. Problem is that this buffer is not linked to a fixed RAM address and will as a result get moved when transitioning between bootloader and app code. The easiest solution to this is to disable RTT logging in the bootloader when you want to logs from the APP. The other solution is to link the RTT block to a fixed RAM section shared by bootloader and app.

Best regards,

Vidar

RE: Problem with custom DFU Buttonless app (bootloader + settings + app .hex with bond_forwarding doesn't run)

Bruno Santamaria — Mon, 04 May 2020 12:58:35 GMT

Update: Actually at point 6 of the post above, I'm not sure why device doesn't reset into DFU. DFU Bootloader has a different address so it should be a different device and could be connected by my phone regardless of the secure bond of my app. So the problem may start there.

I don't need the DFU link to be secure as long as my app is bonded with security with my phone.

2nd Update: In my previous post I found out that there was some problem with my android device, so I tried to repeat point 6 with nRF Connect for Desktop and my Development Kit. This time it worked: Flash SD and DFU, upload App, reupload App with buttonless feature.

However the problem with my app persists. It doesn't answer to my NUS commands sometimes, not all debug messages appear on RTT, etc. See Issue #1 on my original post.