May I deduce the minimum Flash and RAM I need in a module, having the the size of the application source file?

Hi Juan,

You cannot see neither the flash nor RAM usage this way. You need to build the project, and then you will see both. Exactly how you see this depends on the toolchain you use, though. For instance, if building a nRF5 SDK project that use the SoftDevice using Segger Embedded Studio you get the memory usage stated after build has completed:

The above shows the same info, but in the pane to the right you can click the arrow to get more info. Then you will see that in this case the lowest 0x27000 bytes (with this specific SoftDevice) of the flash are reserved, and that is because this is used by the SoftDevice. The rest is for the application. Note that you also need to consider space for persistent data (if relevant, for instance for BLE bonding), and for a bootloader (assuming you want that). For that, it could be good to refer to the memory layout from the bootloader documentation.

Other toolchains will only give you the size of the binary you just built, and you will have to add the SoftDevice size your self (and BL and persistent storage, as always).

Einar

Hi, Einar.
Following your recommendations, when I try to build my SES Project file, I get this error message:

There was an error decoding "C:/Nordic/SDK/nRF5_SDK_15.2.0_WPROTO71/nRF5_SDK_15.2.0_mod/examples/ble_app_uart/main.c" -check the correct file encoding. The file may by corrupted if you save it. Do you want to continue to edit the file?

I am using the last version of Segger Embedded Studio for ARM and a Segger Jlink Base programer&debuger, and the project file has been Built, Run and programed many times in an nRF52840 SoC with no problems whatsoever. I doubt if the problem could be that the project file was made about three years ago, using a modified example from an SDK 15.2.0 toolkit, which may not be fully compatible (?) with the last version of SES (v6.30 64bit) I am using now. The result, in any case, is that I can't complete the building process and see all these memory details you mention in your last message

Could you suggest which could be the error I am making?
Thanks

Juan

Hi Juan,

p143 said:

I doubt if the problem could be that the project file was made about three years ago, using a modified example from an SDK 15.2.0 toolkit, which may not be fully compatible (?) with the last version of SES (v6.30 64bit) I am using now.

No, the error message states that the text file (main.c) is corrupt and that should not be related to SES version conflicts (though it is theoretically possible that there could be a SES bug you are seeing as well, but I have not been able to find references to any such bug).

p143 said:

Could you suggest which could be the error I am making?

Apparently something has corrupted the text file at some point in time. Normally I would expect SES to be able to build the file even though it has been corrupted (as it typically is things like line-ending differences etc. that could happen). That said, the compiler must be able to read it, and that is apparently not the case here. I cannot say what happened to the file or how it is corrupted, and not how to fix it either, but I would start with opening it in a proper text editor (like VS Code, though there are many others) and try to recover. Perhaps it is as easy as copy-pasting the content into another file and fixing the line-endings (either with build in editor functions or command line tools like dos2unix / unix2dos). These are just general ideas, though.

Einar

Thanks, Einar.

Referring to your comments, I shall clarify that the SES Project file we are talking about is one among 28 similar files in which only a few parameters (like conducted output power, advertising frequency, local name etc.) were changed one at a time. In addition, all of these files were tested in a target module and worked as expected. And since before asking you for some help, I obviously checked if the bug was also showing up in the other project files, and it did; tell me please if you agree with me. The error, whatever it is, should not be a corrupted line of text, except if you are ready to accept that corruption could occur in several almost identical files and at the same time. In this case, we would be left with a SES bug, which I honestly think would be a very bizarre reason.
One last comment. All these failures occur without connecting a target module to the computer while issuing the Build command on the SES, just to see the FLASH/RAM details you were mentioning. Only if I would issue a Build and RUN command, the target module should be connected, isn't it?

p143 said:

The error, whatever it is, should not be a corrupted line of text, except if you are ready to accept that corruption could occur in several almost identical files and at the same time.

The only information I have about the error you reported is this, which points to a specific file

p143 said:

There was an error decoding "C:/Nordic/SDK/nRF5_SDK_15.2.0_WPROTO71/nRF5_SDK_15.2.0_mod/examples/ble_app_uart/main.c" -check the correct file encoding. The file may by corrupted if you save it. Do you want to continue to edit the file?

And this clearly points to a corruption of the main.c file (without specifying more). I am not able to say more of if this, unfortunately.

p143 said:

All these failures

Are you getting more errors? Then please let us know which (copy-past them here).

p143 said:

Only if I would issue a Build and RUN command, the target module should be connected, isn't it?

Yes, there i no need to connect any HW in order to build the project.

p143 said:

The error, whatever it is, should not be a corrupted line of text, except if you are ready to accept that corruption could occur in several almost identical files and at the same time.

The only information I have about the error you reported is this, which points to a specific file

p143 said:

There was an error decoding "C:/Nordic/SDK/nRF5_SDK_15.2.0_WPROTO71/nRF5_SDK_15.2.0_mod/examples/ble_app_uart/main.c" -check the correct file encoding. The file may by corrupted if you save it. Do you want to continue to edit the file?

And this clearly points to a corruption of the main.c file (without specifying more). I am not able to say more of if this, unfortunately.

p143 said:

All these failures

Are you getting more errors? Then please let us know which (copy-past them here).

p143 said:

Only if I would issue a Build and RUN command, the target module should be connected, isn't it?

Yes, there i no need to connect any HW in order to build the project.