This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Help activating bootloader logs on RTT

We successfully built the mesh bootloader, but want to get RTT working with the bootloader logs inside SEGGER.

We were following this two posts post1 post2 to achieve our goal.

After activating the -DBOOTLOADER_DEBUG_ENABLE=ON option on ninja and changing the declarations in the SEGGER_RTT.c file to

static char __attribute__((section(".rtt_ac_up"))) _acUpBuffer  [BUFFER_SIZE_UP];
static char __attribute__((section(".rtt_ac_down"))) _acDownBuffer[BUFFER_SIZE_DOWN];
SEGGER_RTT_CB __attribute__((section(".rtt_segger"))) _SEGGER_RTT;

I need to know where I can edit the SECTIONs used above. I think they have to be defined in a linker file, with the *.ld extension. For reference we are using a modified light switch client example from mesh sdk 3.1.0, that used softdevice version 6.1.0. We recently updated the project to use mesh SDK 3.2.0, and changed on the project definitions to use the 6.1.1 version of the softdevice in the additional load file option.

I have been searching around to pinpoint which .ld file the project uses. I supposed it was one inside the linker folder inside the project folder, but adding the SECTION definitions to the most recent .ld file does nothing, I get a 'region `UNPLACED_SECTIONS' overflowed by 1272 bytes' message regardless of the definition of the sections.

Parents
  • The linker folder inside the project folder doesn't seem to have any use. The linker script that matters is inside build/${name_of_project}_${build_type}/obj/${name_of_project}.ld.

    I think the flash_placement.xml file is used by SEGGER to generate the linker script referred above at build time, so we should edit flash_placement.xml.

  • rmarques said:
    I think the flash_placement.xml file is used by SEGGER to generate the linker script referred above at build time, so we should edit flash_placement.xml.

     That is correct. Segger embedded studio uses the falsh_placement.xml file for the flash placements, but I believe it also uses some of the project settings, so check project settings -> build -> Memory segments, and project settings -> linker -> section placement macros as well.

    It depends a bit on what you want to change how many of these you have to modify.

    You are talking about the mesh bootloader, or do you use the normal SDK's bootloader?

    Best regards,

    Edvin

  • Sorry. I just saw 3.1.0 somewhere in your text. For 3.2.0 and SDK15.3.0, v3.40 of SES should be fine.

    for 3.2.0, this guide is the updated one, but it should be the same, just with new recommended settings, such as --sd-req 0x00AF.

     

    rmarques said:
    When intended for the device connected to serial it works, when intended for others it fails on the others, the problem is on the recovery of lost packets.

     What are the other nodes programmed with? Do they have the DFU example running? The reason I ask whether it is the DFU example, or something built on the serial example, SDK\examples\serial, is that this example works a bit different.

    How about the environment that you test in? Are the nodes close to one another? Did you change anything with regards to relay count? How many nodes do you use to test? Does the DFU fail on all devices, or only some?

  • I have two nodes side by side, both programmed with the DFU example built in debug mode, with a __LOG inside the nrf_mesh_dfu_rx function so I can inspect which DFU packets are being received using the RTT. The boards that I am using are two nRF52840 DKs with softdevice 6.1.1. DFU aborts on the node that is not connected to the computer.

  • Are you using nRF52840 Development Kits, or some other HW?

    I tested it just now, and I don't see the same issue (using SDK_mesh3.2.0 and SDK15.3.0).

    Have you done any changes to the DFU example project?

  • I'm using nRF52840 DKs.

    The only change to the DFU example project were logging the received packets in the RTT.

    It seems this is a curret problem on the mesh DFU, confirmed by the mesh team. Please advise if not true.

    In the meantime, if I could get help activating the logs on the Bootloader, that would still be handy.

  • Ok. I was not aware. I tested the DFU with this SDK, and it looks like it worked here, but maybe I was lucky, and didn't have any packet loss. I suggest that you follow up in the ticket that you linked to, where the issue was reported. 

    BR,

    Edvin

Reply Children
Related