5 years, 8 months ago.

Error Warning L6320W, ignoring --keep command??

I'm using a LPC1768 Mbed development board. Whilst compiling my program i get the following error

error code returned

Error: Warning: L6320W: Ignoring --keep command. Cannot find argument 'os_cb_sections'.

The code I'm trying to compile is

include the mbed library with this snippet

/* ELEC1620 Application Board Example

Example of the Tone library to interface with the DAC

(c) Dr Craig A. Evans, University of Leeds, March 2017

*/

#include "mbed.h"
#include "Tone.h"

Tone dac(p18);

Serial pc(USBTX,USBRX);  

AnalogIn pot(p20);

int sum_array(const int input_array[]);

// Super Mario Theme Tune
const int note_array[] = {
    NOTE_E7, NOTE_E7, 0, NOTE_E7,
    0, NOTE_C7, NOTE_E7, 0,
    NOTE_G7, 0, 0,  0,
    NOTE_G6, 0, 0, 0,

    NOTE_C7, 0, 0, NOTE_G6,
    0, 0, NOTE_E6, 0,
    0, NOTE_A6, 0, NOTE_B6,
    0, NOTE_AS6, NOTE_A6, 0,

    NOTE_G6, NOTE_E7, NOTE_G7,
    NOTE_A7, 0, NOTE_F7, NOTE_G7,
    0, NOTE_E7, 0,NOTE_C7,
    NOTE_D7, NOTE_B6, 0, 0,

    NOTE_C7, 0, 0, NOTE_G6,
    0, 0, NOTE_E6, 0,
    0, NOTE_A6, 0, NOTE_B6,
    0, NOTE_AS6, NOTE_A6, 0,

    NOTE_G6, NOTE_E7, NOTE_G7,
    NOTE_A7, 0, NOTE_F7, NOTE_G7,
    0, NOTE_E7, 0,NOTE_C7,
    NOTE_D7, NOTE_B6, 0, 0
};

// 8 corresponds to 1/8
const int duration_array[] = {
    8,8,8,8,
    8,8,8,8,
    8,8,8,8,
    8,8,8,8,

    8,8,8,8,
    8,8,8,8,
    8,8,8,8,
    8,8,8,8,

    6,6,6,
    8,8,8,8,
    8,8,8,8,
    8,8,8,8,

    8,8,8,8,
    8,8,8,8,
    8,8,8,8,
    8,8,8,8,

    6,6,6,
    8,8,8,8,
    8,8,8,8,
    8,8,8,8,
};


int main()
{
    pc.printf("Starting main");
    while (1)
    {
        pc.printf("Start of while loop\n");
        float bpm_precalc = pot.read();
        pc.printf("bpm_precalc is: %2f\n",bpm_precalc);
        float bpm = ((bpm_precalc*120)+60);
        pc.printf("bpm is: %2f\n",bpm);
        pc.printf("Initiaing DAC\n");
        dac.init();
        pc.printf("DAC initiated\n");        
    
        pc.printf("Calculating length\n");    
        int n = sizeof(note_array)/sizeof(int);
        // tell it the number of notes, arrays, BPM and whether to repeat
        pc.printf("Playing melody\n");
        dac.play_melody(n,note_array,duration_array,bpm,false);
        pc.printf("calculating time to wait");
        int total_beats;
        total_beats = sum_array(duration_array);
        float time = (total_beats*bpm)*60;
        pc.printf("waiting for: %2f secconds",n);
        wait(time);
        pc.printf("End of while loop\n");
    }
}

int sum_array(int input_array[])
{
    int total = 0;
    int beats = sizeof(input_array)/sizeof(int);
    for (int i = 0; i < beats ; i++){
        total+=input_array[i];
    }
    return total;   
}

Does anyone have any idea how i solve the error (there's no help page listed)?

I'm getting the same error. LPC1768, programming on the web application. The documentation for mbed.bld is also unable to load at all, even after multiple refreshes.

posted by Matthew Zilvetti 01 Apr 2019

I'm getting the same error and , searching for answers, found this is not an isolated incident. In the nearly 2 months of history since this has been posted, I can't see a single conclusive answer, or comment, other than the templated "update your libraries". That's how we got in this situation in the first place. Need a real solution asap.

posted by Andrew Fox 30 May 2019

I got this error when I tried to pass a

Incorrect type

int*

to a function which wanted a

Wanted Type

int**
posted by Noah Huppert 06 Nov 2019

25 Answers

5 years, 8 months ago.

Same issue here. Any ideas anyone?

5 years, 8 months ago.

If you found a solution for this warning please let me know because I get the same Warning in my code. It was working fine one moment and then it stopped working.

Thanks in advance.

5 years, 8 months ago.

I cannot figure out why I get this error. A few moments ago it was working. Maybe an mbed update caused this?

5 years, 8 months ago.

I have the same problem. Following this thread

5 years, 6 months ago.

Hi,

I had the exact same problem compiling a program for the NUCLEO-F767ZI board.

It was caused by a declaration of an array too big to fit in the RAM:

stack too big

/*****************************************************************************/
/* STACK                                                                     */
/* max stack size in bytes                                                   */
#define Alysee_MaxStackSize 1000000
/* the stack itself                                                          */
Alysee_char Alysee_Stack[Alysee_MaxStackSize];

since the RAM is 512K, the 1Mb stack was a bit optimistic :-)

Once the mbed lib updated and the size of that stack set to a more realistic 100k, it compiled OK. Yet, a more explicit error message would be nice.

So maybe this is usefull for some other people who have the problem: check the size of your code/data.

5 years, 8 months ago.

I also have this error when compiling for Nucleo STM32F030R8 target with OS2

5 years, 6 months ago.

happened to me when I tried to use a pinname to declare to different functions. Example : MyClass1 myvariable1(D2,D3); MyClass2 myvariable2(D2,D3);

5 years, 8 months ago.

Same error (Nucleo STM32F401re target) but not on every program so I copied and pasted source and header files into another program and it compiled.

Not an ideal situation or fix.

I might add that I now have the following error in the new program:

Warning: Incompatible redefinition of macro "DEVICE_ERROR_RED" in "extras/mbed/TARGET_NUCLEO_F401RE/TARGET_STM/TARGET_NUCLEO_F401RE/device.h", Line: 66, Col: 10 Resourse device.h

However, if I now compile the original program it now compiles with 0 warnings and 0 errors.

posted by Jess Cheng 03 Apr 2019
5 years, 8 months ago.

Same issue... I found the following forum thread: http://www.keil.com/forum/64102/warning-l6320w-ignoring-keep-command-cannot-find-argument/

But since I'm a beginner I don't know where to find this cppinit ... any clues?

No proper solution for this error still.

posted by L B 17 Apr 2019
5 years, 8 months ago.

Same problem here with Nucleo STM32L432KC. Mbed library updated, nothing changes...

Also in my case other programs using the same board are compiled without errors/warnings.

5 years, 6 months ago.

I had the same issue, my prototype was also not matching the function implementation.

<<code title=In my .h file>>void periodicCallback(EventQueue *queueBLE, uint16_t* data);<</code>>

<<code title=In my .c file>>void periodicCallback(EventQueue *queueBLE, uint16_t data);<</code>>

5 years, 8 months ago.

Same problem. A number of other programs compiling just fine. The one I really need to compile right now gets this error. Updating libraries does not help. Something is clearly wrong on the server side (what else is new)

Created a blank project containing only the mbed library, got the same error

posted by Steve Marmer 08 Apr 2019
5 years, 8 months ago.

I only get that Error when I try to use a function in Main thats in a different class.

  1. include "mbed.h"
  2. include "RECEIVERS_UART.h"

RECEIVERS_UART rc; Serial pc(SERIAL_TX, SERIAL_RX);

int main() {

pc.baud(115200);

rc.receivers_uart_init();

pc.printf("%c",rc.read_receiver_1()); } }

If i comment out "rc.receivers_uart_init();" , the program runs without errors.

Anyone have any clue what the issue could be?

Thanks in advance.

Just solved my case of this... like you, main() was calling into something defined in another file. The decl was in the *.h file. But the .c file was missing the actual instantiation - I had commented it out. So, my guess, the linker is finding the problem, but not reporting it properly. Not sure if this will help you, but check that "rc" is properly instantiated somewhere.

posted by Steve Marmer 08 Apr 2019

Sorry I don't fully understand what you mean by checking whether "rc" object is properly instantiated.

Can you please give me an example ?

Thanks

posted by Abdirahman Abdimalik 08 Apr 2019

Sorry, your first line "RECEIVERS_UART rc;" - didnt notice earlier, but that is where "rc" is instantiated. I ran into this problem yet again, this time because I created a large array and blew available ram. Shrinking this array made the problem go away. So again, looks like linker issues not getting reported properly. Your example looks quite small so I'm not sure what to suggest. You do have a RECEIVERS_UART.c* in your project, I assume, and it defines the RECEIVERS_UART class methods?

posted by Steve Marmer 09 Apr 2019
5 years, 3 months ago.

In my case, I had a syntax error in a '.cpp' file. It seems L6320W is a generic error/warning.

5 years, 8 months ago.

I get the exact same error when compiling the second line of this code, the first line compiles just fine (using NUCLEO F746ZG):

Error line

_terminalMirror.start(terminalMirror);
_serialCommand.start(serialCommand);   // commenting out this line successfully compiles

both threads are setup in the same way. I can't understand why this particular line causes the error?

5 years, 3 months ago.

Using the LPC1768, I get this issue on some code if I create a "new project" and then add my code libraries. I don't seem to be able to revert to earlier mbed library versions to get rid of it anymore in a new project.

So far, the only way I have gotten rid of it was to use an old "import program" link from an old published program that brings in an older mbed library (and then don't update) and use that as a starting point to add code.

I found one of these errors and fixed it. There was an undefined Serial object. Moved the code to another older project (perhaps it is using the older compiler/linker?) and that one says "undefined object" in the error message as one would expect - unlike the confusing one in the current cloud compiler, "Cannot find argument 'os_cb_sections'". The undefined Serial object was in an include file's code. Wonder if perhaps some very helpful compiler/linker error messages are not showing up in the GUI?

Hey Jim, I have exactly the same problem. I'm trying to create a new version of an older program and when I include the libraries that I'm using in the older version into the new program this error message appears. When I clone the older one and change the code, no errors happen. If you figure out any other clue on how to solve this weird error, please share it with us. Regards Luciano

posted by Luciano Chaves 26 Oct 2019
5 years, 8 months ago.

I just found out why this happens. Your prototype doesn't match your implementation. Specifically in terms of the const keyword.

prototype

int sum_array(const int input_array[]);

implementation

int sum_array(int input_array[])

I don't know why the compiler spits out the errors that it does, but I am reasonably confident that correcting the mismatch will allow the code to compile.

5 years, 8 months ago.

I experienced the same error, but I think mine had a different cause.

I wrote my code using the Nucleo F303K8 with the intention of transmitting data over Bluetooth using 2 sensors. The code worked fine with just the first sensor until I added the second sensor and the libraries that came with it. Turning the newly added code into comments didn't solve the problem, neither did changing most of it except for a simple integer print.

I had to make the following changes to solve it (mind you it worked before):

From

Serial bt(D1, D0); // TX, RX

To

Serial pc(D1, D0); // TX, RX

(and do the same for printf and baud commands)

My theory is part of the added library already included a Serial pc() assignment I wasn't aware of, so it didn't mix well. Hope this helps someone in the future.

5 years, 7 months ago.

Same problem: Post-compile Error that aborts the compiler, not a hint as to the cause:

Quote:

Error: Warning: L6320W: Ignoring --keep command. Cannot find argument 'os_cb_sections'.
Info: Unable to download. Fix the reported errors...

Doesn't anyone have a handle on this yet? What and where are 'os_cb_sections' ???

5 years, 7 months ago.

I get the same issue. In my case it occurs when I use a function which is correctly declared in a header file but which has no definition - usually a simple typo in the definition name. Previously (a few weeks ago) the compile process would give the name of the function it was missing and the module in which it was used; now it just display this generic L6320W error (probably from the linker) which doesn't help at all in finding the typo.

Thanks! I solve the L6320W error with your help.

posted by Ignacio Carballeda 29 Aug 2019
5 years, 7 months ago.

Had the same error compiling for the LPC1768, for me it came from the fact that I had declared the name of the function, but had forgotten to implement it. So the compiler must have been looking for the implementation and did not realize what to do with a missing function.

5 years, 4 months ago.

Hello guys, I have the same problem qith F41RE and QCM5883 library. any idea to solve int? thanks in advance Lorenzo

5 years, 7 months ago.

Hi everyone! I solved this problem.

I just ran over this same compiler error message while trying the examples of a MAXREFDES100 board (based on a max32620hsp). What I found was that the way the examples are implemented for this board are not compatible with the very latest versions of the peripheral libraries, but the warning L6320W came from the mbed library.

The way I solved it was returning the mbed library to an older version. For my case, I used a date prior to the date of the examples (November 27, 2017)

https://i.imgur.com/oY2xrGw.png

I'm just starting to develop code for mbed devices, so I'm not sure what new additions came with newer versions, or how to rewrite the code to comply with it, but for now, this works for me.

Good luck!

It still showing Error: Warning: L6320W: Ignoring keep command. Cannot find argument 'os_cb_sections'.

posted by Jeffry Papin 08 May 2019
5 years, 7 months ago.

I'm not sure but I believe the compiler on Mbed is using ARM6 where it was using ARM5 prior to January 2019.

I and many more users have noticed issues since then.

Again I'm not sure but it appears to me that the 'warnings' have some impact on the compile process and backs out with these errors.

If you can get your program and libraries to give no warnings then its pretty much stable.

Now the problem.

Mbed libraries have too many warnings, zero warnings is the only tolerable condition.

Every Mbed update creates further errors and warnings in users libraries and program code.

I have almost completed a library over the past several months that is now infested with warnings since the last update. I can't keep winding back to an older version because there are issues that have been resolved in a subsequent update.

In general Mbed libraries prior to December 2018 are reasonably stable.

I do not know who is actually writing the Mbed libraries and I'm not a programmer, but from a business point of view I can tell you currently it is imperative that these warnings are rectified with the utmost urgency before this Mbed project collapses.

There is no way a user can have confidence with this situation, particularly from a commercial point which Mbed lends itself to.

I believe that Mbed will be a very good system, but what do we do in the mean time? We simply can't use it.

I'm having the same errors listed above on an existing pieceof code. It's in use in a commercial product, and was stable, until the client asked to add some features. The "updates" to mbed libraries make compiling the existing codebase a nightmare, before even adding the new features. You're absolutely correct, from a business perspective there's no stability and I have already started advising people not to use mbed for this very reason. I've had numerous issues over the years and rarely have the support forums been useful, well meaning yes, but productive no.

posted by Andrew Fox 30 May 2019
5 years, 4 months ago.

Hitting this problem with nRF51-DK with all the examples. Reverting to an earlier version of mBed fixed it. I bisected it, and Revision 169 (release 162 on the 22nd of June 2018) does NOT work, but the previous one - 168 (also release 162 (??) on the 24th of May 2018) DOES work.

I think they don't have a proper CI system. Surely it would pick up things like this?