Help activating bootloader logs on RTT

[rmarques]

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.

[rmarques]

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.

[Edvin]

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

[rmarques]

Yes, section placement macros are used inside the flash_placement.xml file.

I am talking about the mesh bootloader.

I am now looking at this post to see if I can get logs working.

[Edvin]

You are maybe aware of this, but most of the links you have provided are not for the mesh bootloader, but the "normal SDK" bootloader. Is there any specific reason why you need to enable logging in your mesh bootloader? Or why you need to change it at all?

[rmarques]

I am not able to run DFU over the mesh for large firmware packets (other than the blinky destributed with the mesh SDK) and I suspect the problem is on the mesh bootloader. I have already posted here about this.

I want to have the LOGs working on the bootloader side so I can investigate on my own at least until I have confirmation of the state of the DFU over mesh from nordic.

Since this is so hard to debug right now, we are thinking of implementing our own transport layer on the app side and just use the bootloader to transfer the firmware from the nodes' ram into flash, because that works.

[Edvin]

Ok. What are the symptoms of your large firmware images not being able to run? 

The mesh DFU is a background DFU, meaning that the bootloader only copies the firmware to the correct placement once the upload is finished, so it doesn't handle the upload. 

I have tested the Mesh DFU with larger files, and it should work. Have you tried e.g. creating a DFU image of the dfu example? Does that work in your case?

Maybe you can tell me about the symptoms you see when it doesn't work? Do you get any messages returned from the nrfutil command when you try to update? Do you get any useful information from the application log on the nRF52840?

Also, can you tell me what version of SES you are using? 

Best regards,

Edvin

[rmarques]

Edvin said:

Ok. What are the symptoms of your large firmware images not being able to run? 

After a while I get "Abort event. Reason: 0x3" on the targets, due to receiving too many packets after a lost segment was requested and not received/processed by the bootloader, I think.

Edvin said:

The mesh DFU is a background DFU, meaning that the bootloader only copies the firmware to the correct placement once the upload is finished, so it doesn't handle the upload. 

I know. Is there a proper way to upload a packet from the application side programmatically?

Edvin said:

I have tested the Mesh DFU with larger files, and it should work. Have you tried e.g. creating a DFU image of the dfu example? Does that work in your case?

It did not, same thing as above. It did work with blinky though.

Edvin said:

Maybe you can tell me about the symptoms you see when it doesn't work? Do you get any messages returned from the nrfutil command when you try to update? Do you get any useful information from the application log on the nRF52840?

I don't get anything useful on the nrfutil command, the sender board just keeps sending the packets until the end of the firmware image. I added some log messages inside the nrf_mesh_dfu_rx function in nrf_mesh_dfu.c so I could track the packets being received. I noticed that even though the lost packets were being asked for with the FFFB handle and received with the FFFA handle, after the second or third lost segment, FFFB handles were being sent from the target for packets already received with the FFFA handle.

Edvin said:

Also, can you tell me what version of SES you are using?

SEGGER Embedded Studio for ARM
Release 4.12  Build 2018112601.37855
Linux x64