WAI YUNG

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

8 years, 12 months ago.

LPC1114FN28 mbed online vs LPCXpresso

Dear all, it is a question related to LPC1114FN28. I have tried following code using mbed online. It compiles fine, flash memory is 24.8 kB in size, RAM is 1.4 kB in size. I then exported this project to LPCXpresso v7.9.2_493. It would not build because the flash memory size is beyond 32 kB. Why?

I change settings to NewlibNano, optimize for size, still would not build because of the size is larger than 32 kB

#include "mbed.h"
#include "SDFileSystem.h"


SDFileSystem sd(dp2, dp1, dp6, dp26, "sd");
 
int main() {
    printf("Hello World!\n");   
 
    mkdir("/sd/mydir", 0777);
    
    FILE *fp = fopen("/sd/mydir/sdtest.txt", "w");
    if(fp == NULL) {
        error("Could not open file for write\n");
    }
    fprintf(fp, "Hello fun SD Card World!");
    fclose(fp); 
 
    printf("Goodbye World!\n");
}

2 Answers

Johannes Stratmann
8 years, 11 months ago.

I can confirm this behaviour, I've used your sample code in LPCXpresso v8.0.0, the result is 'region `MFlash32' overflowed by 3772 bytes'. This is the smallest that I can get, tried different compiler/linker settings. Is there an option to get the map file from the online compiler? Maybe you can compare the results. The difference in code size is really huge, there must be some hidden magic setting for the online compiler.

Thank u for the confirmation. Dear mbed team, can u comment on this issue please? I got 6612 bytes overflow

posted by WAI YUNG 29 Dec 2015
Nenad Milosevic
8 years, 11 months ago.

The mbed online compiler is based on Keil MDK ARM compiler, while LPCXpresso is as far as i know based on the free GCC ARM compiler. In most cases the Keil compiler i think does a much better job in the efficient optimization of code and i think the standard libs are better optimized too. On the other hand the offline version of the Keil compiler costs $$$, so it's often not an option for the 'normal' hobbyist, when working with micros with Flash sizes > 32 KB.

But there is a free (evaluation) version of the Keil compiler, which can generate code up to 32 KB. So if that's the max size that you need, you can download it from www.keil.com.

Best regards
Neni

Thank u. I tried Keil demo version. The project will not build. I am not familiar with Keil.

* Using Compiler 'V5.06 update 1 (build 61)', folder: 'C:\Keil_v517\ARM\ARMCC\Bin' Build target 'mbed NXP LPC1114' linking... .\build\LPC1114FN28_Blinky.axf: Error: L6406E: No space in execution regions with .ANY selector matching arm_exceptions_mem.o(.text). .\build\LPC1114FN28_Blinky.axf: Error: L6406E: No space in execution regions with .ANY selector matching sdfilesystem.o(.constdataZTV12SDFileSystem). .\build\LPC1114FN28_Blinky.axf: Error: L6406E: No space in execution regions with .ANY selector matching fatfilesystem.o(.constdataZTV13FATFileSystem). .\build\LPC1114FN28_Blinky.axf: Error: L6406E: No space in execution regions with .ANY selector matching memmovea.o(.text). .\build\LPC1114FN28_Blinky.axf: Error: L6406E: No space in execution regions with .ANY selector matching dfixul.o(.text). .\build\LPC1114FN28_Blinky.axf: Error: L6406E: No space in execution regions with .ANY selector matching ctype_c.o(.constdata). .\build\LPC1114FN28_Blinky.axf: Error: L6406E: No space in execution regions with .ANY selector matching 0sscanf.o(.text). Not enough information to list image symbols. Not enough information to list the image map. Finished: 2 information, 0 warning and 90 error messages. ".\build\LPC1114FN28_Blinky.axf" - 90 Error(s), 0 Warning(s). Target not created. Build Time Elapsed: 00:00:04

posted by WAI YUNG 30 Dec 2015

I think the gcc optimization cannot be so worse that it adds about 12k code. I don't have the LPC1114, so I changed the platform setting and exported to a LPC1347. There I see that I get different code for the SDFilesystem. But the size is similiar to the LPC1114 project, about 38k. When I remove the SDFilesystem and use a simple SPI (and printf()) the gcc generates 18.5k of code, compared to 16.7k for SPI and 27.9k for FS. Is it really bad gcc optimization? Tried also Keil v5, it creates about 34k, also more than the online Compiler. I found also that the online compiler should be an ARM compiler like http://ds.arm.com/ds-5/build/ , not he Keil µVision.

posted by Johannes Stratmann 31 Dec 2015

Thank u for the feedback. Basically, all of us have experienced more than 32 kB code using offline compilers. Is there way to let mbed development to respond to this question?

From this link http://ds.arm.com/ds-5/compare-ds-5-editions/

We cannot evaluate Cortex M using community edition

posted by WAI YUNG 01 Jan 2016

First of all, you probably will need to download and install the MDK v4 Legacy Support (http://www2.keil.com/mdk5/legacy/), because the Online Compiler is still based on MDK ARM v4. Otherwise the exported project will generate a lot of compiler errors if you don't fix all the paths etc. by hand. With the legacy support installed it should compile just fine from the exported project (that was at least my experience).

Furthermore Keil is owned by ARM, so yes, the Compiler in the MDK ARM Package is the ARM CC Compiler (which is used online too). The difference is the IDE toolchain only (http://www.keil.com/arm/rvcomparison.asp). Actually DS can use the GCC compiler too while uVision is integrated with ARM CC compiler only. But in the online IDE the ARM CC is used for sure.

I had also experienced quite substantial code size differences with the ARM CC (in uVision) as opposed to the online compiler, until i did some digging into the Python toolchain scripts on mbed github and found out all the compiler switches they are using. After putting these into uVision compiler settings i get almost exactly the same code sizes like with the online compiler (differences of maybe some 100 Bytes) and still functional code.

First you should export your program (online) for uVision, then open the project file (*.uvproj) in uVision v5 with legacy support installed. Open the "Options for Target" window by clicking on the corresponding toolbar icon (or via "Project" menu). On tab "Target" you might want to check that the checkbox "Use MicroLIB" is set for targets with small flash sizes. This should actually already been correctly set in the exported project file. On tab "C/C++" you should set the Optimization to "Level 3 (-O3)" and set the checkbox "Optimize for Time". You can get even smaller code sizes (smaller than with the online compiler) by leaving "Optimize for Time" unchecked, but the corresponding online compiler setting is checked, and you might get some performance penalty without it. The last and most important step is to put the following line into the "Misc Controls" textbox:

--gnu --split_sections --brief_diagnostics --restrict --multibyte_chars --md --no_depend_system_headers --cpp --no_rtti

These are all the above mentioned compiler switches. I'm by no means a compiler expert, so i don't know exactly what all of them do, but the impact on the resulting code size is huge. Then you can click "OK" an compile your project.

That's all and you might want to save one such Project as a kind of template for future reference, so you can easily copy and apply these settings for other exported projects again.

Best regards
Neni

posted by Nenad Milosevic 01 Jan 2016