Maximum size ELF file?

[Jose Cazarin]

Is there a maximum size for the elf file generated after the build is done?

Our elf file is 11.057 kb right now. And when we try to program our board (nrf52840 based) using the Visual Studio interface (Debug-> Program and start without debugging) it fails at the end of the programming, it shows the attached screen. But if we try to program the board using NRF command line tools (nrfjprog) it works fine

I know that the Visual Studio Interface option uses the elf file to write to the board, and the nrfjprog uses the .ihex file. So, is there anyway to fix this?

 

Thanks!

 

 

Attachments:

You must be logged in to view attached files.

[Jose Cazarin]

Just to be clearer: when our code was smaller (elf file around 1.43 Mb) we didnt have this error

• This reply was modified 4 years, 10 months ago by Jose Cazarin.

[support]

Hi,

The “Failed to program sections” error is shown when VisualGDB fails to verify the FLASH memory contents after programming. Please try clicking the “Show Details” button to view more details or simply disable memory verification via Tools->Options->VisualGDB->Embedded->Other->Verify Memory when Programming.

P.S. You can find a find a detailed and searchable list of all VisualGDB settings here: http://visualgdb.com/settings/

[Jose Cazarin]

Thank you!

If I disable memory verification, the error goes away but the board is not successfully programmed

This hints that there’s really a problem with the flashing. When I click the “show details” three windows appear: GDB session, Exception details, and JLinkGDBServerCL

I’m attaching here the messages in these three windows because I could not figure out what may be causing the problem. I guess its something related to the size of the binary file generated because when our codebase was smaller the programming worked well. I would like your help in trying to find out what’s causing this. I had to manually merge the 3 files into one file because I cannot attach more than one file in my post. So I added some separators for each session in the form of a header with a long sequence of “=”

The main reason why I want this to work is that this seems to be related to the fact that I cannot run the tests on the code anymore (using Google Tests). When I try to run the tests, it seems that Visual Studio flashes the device in the same way it does when I click in “Program and Start Without Debugging”. But after that, the Testing Suite just hangs and does not run the tests. I tried removing all tests and adding just a dummy test with ASSERT_EQ(true, true) and not even this test runs. So I guess the device is not being programmed correctly, that’s why the Test Suite hangs. And if I go back to an old version of our code (into which the programming with the “Program and Start Without Debugging” option works), the tests run fine.

 

 

 

Attachments:

You must be logged in to view attached files.

[support]

Thanks for the logs. It looks like the problem is somewhere between gdb and the Segger GDB stub.

The easiest way to work around it would be to disable memory programming via VisualGDB Project Properties -> Debug Settings and then run nrfjprog as a custom pre-debug action. This will affect both the regular debug sessions and the “Program without debugging” command.

If you would like to narrow down the true cause of the problem, please try running gdb and JLinkGDBServerCL manually from the command line, connect gdb to the J-Link server and try programming and verifying the memory (load and compare-sections commands). If you can reproduce the problem, please check with Segger support, it might be a bug on their side (or a missing setting related to FLASH memory protection).

Another troubleshooting technique would be to start a regular debug session and use the VisualGDB’s graphical memory verification tool (chip icon on the GDB Session window). It will show the exact differences between the ELF file and the device memory, possibly pointing to the root cause.

[Jose Cazarin]

I found the problem! I was taking a look at the Debug Settings to try to implement the workaround that you suggested and I realized that our debug setting was set for the NRF2832 (which was the device that we started in our project). But now we are using an NRF2840 (which has two times the flash size than the NRF2832). Some time ago our code wasn’t using more than 50% of the flash so we had no problems. But now we got past this threshold so we need to update the debug settings for the NRF2840.

Thank you so much!

[Author]

Posts