Hello,
I had exactly the same problem. The problem is very easy to reproduce. I use a complete clean RIDE7 installation BN28, CD_STM32-Primer_BN28.zip.
Start a new primer2 application. Call the function "sprintf" as an example. (uart0_putchar and small printf option selected)
The application will work fine in debug mode, i.e when loaded in Primer2 from RIDE7. but when called from add_to_Circle.bat the linking will fail.
The function needed are included in syscalls.c,, but the strange part is that if I compile syscalls.c together with my application and make a lib of them the linking still fails. It seems that the Circle_mgr program only link the functions that are part of the application.o (though it is in a .lib file with both Appplication.o and syscalls.o)
I tested to move the missing function in linking from syscalls.c, _sbrk into Application.c and then the linking works fine.
When using a lib, It seems that only functions that is implicit called from with within Application.o are linked. To prove this I tested to call one of the functions that couldn't be linked (_ttyisa) from within Application.c and the linking works for that function.
It seems that there is some strange behavior of the linking performed by circle_mgr.exe that makes the linking fail if the functions needed are not called from within Application.o.
(My guess is the above problem has something to do that the sbrk has been moved to a separate library and the circle_mgr don't include that if needed.)
(An easy way to make a workaround is in the beginning of the Application.c call
syscalls.c; #include "syscalls.c". This will make the linking work. To add the syscall.o in in a lib didn't work for me. Note the difference)
Per
