Program chip using st-link in Atollic IDE

[ayaka]

Posted on June 30, 2010 at 01:19

Program chip using st-link in Atollic IDE

[sjo2]

Posted on May 17, 2011 at 13:56

Surely you just redirect syscalls as you would with any newlib based toolchain.

As for the conversion, you could always use the cmdline, eg.

arm-atollic-eabi-objcopy.exe -O ihex file.elf

Cheers

sjo

[adrian239955_stm1_st]

Posted on May 17, 2011 at 13:56

Hmm, despite all the glossy ST press releases about low-cost development routes for the STM32, I think TrueStudio is turning out to be a dead-end. First I found printf() cannot be directed to anything at all, now it seems as if there may be no way of getting a .hex file out of the lite version.

http://www.atollic.com/index.php/truestudio/building/tsbuilderflashconverter

Let's hope the clever people around here have some suggestions for work-arounds - or show where I've been going wrong :\

[sjo2]

Posted on May 17, 2011 at 13:56

Just done a quick test using my own version of syscalls - working fine for me with printf and the lite version (1.4).

int _write_r(void *reent, int fd, char *ptr, size_t len)

{

    ...

    return len;

}

Also for the conversion to hex look at my code snippet above (repeated also below).

arm-atollic-eabi-objcopy.exe -O ihex file.elf

Cheers

sjo

[adrian239955_stm1_st]

Posted on May 17, 2011 at 13:56

Program Files\Atollic\TrueSTUDIO STM32 Lite 1.4.0\Library\STM32F10x_StdPeriph_Lib_V3.3.0\Project\STM32F10x_StdPeriph_Template\TrueSTUDIO\note.txt

''The C runtime library include many functions, including some that typically

handle I/O. The I/O related runtime functions include printf(), fopen(), fclose(),

and many others.

It is common to redirect the I/O from these functions to the actual embedded

platform, such as redirecting printf() output to an LCD display or a serial cable,

or to redirect file operations like fopen() and fclose() to some Flash file

system middleware.

The free Lite version of TrueSTUDIO do not support I/O redirection, and instead have do-nothing stubs compiled into the C runtime library.

 

 

To support printf() redirection in the full version, just add the following code

in in _write() function in the TrueSTUDIO Minimal System calls file ''syscalls.c''

located at TrueSTUDIO Pro install directory.''

This note from ST makes it appear that there's no way round it although maybe they could have followed the last paragraph with something like ''To support printf() redirection in the Lite version...'' - but maybe they have some kind of deal going on.

As for programming, both the free ST flash loader demo and the ST-Link utility appear to load only .hex or .bin files. So far I'm not having much luck finding out how to convert between the two.

[adrian239955_stm1_st]

Posted on May 17, 2011 at 13:56

Thanks for that sjo :) This could be of great interest to people looking for a solution to the limitations of this inexpensive but otherwise highly effective route to code development using the ST-Link. For those of us with little or no experienced with the GNU tools  is there any chance of some pointers to more detailed instructions on making the necessary changes in the TrueStudio environment?

[sjo2]

Posted on May 17, 2011 at 13:56

Just noted that they have locked down the newer version of arm-atollic-eabi-objcopy.exe, so just copy (and rename) objcopy from another tool, eg. codesourcery and all is working as expected.

Make sure you use a eabi version to match atollic.

Cheers

sjo

[sjo2]

Posted on May 17, 2011 at 13:56

The most commonly used is to redirect printf output.

To do this just create the following function

int _write_r(void *reent, int fd, char *ptr, size_t len)

{

    /* do something here */

    return len;

}

more details about the various syscalls can be found on the newlib docs:

http://sourceware.org/newlib/libc.html#Reentrant-Syscalls

Just as a note the newlib stdio functions are still a bit heavyweight for small targets like the stm32, probably better of searching for lightweight versions, there are lots on the net.

You can also save a bit of space if you use the integer versions of the functions, eg. iprintf rather than printf.

Cheers

Spen

[ayaka]

Posted on May 17, 2011 at 13:56

There's one I can think of.

That's when you rename the project, it seems to give a linker error.

I have not really looked into this problem but gives me error such as ''undefined reference to '_ebss'''.

[hooman14]

Posted on May 17, 2011 at 13:56

having the same issue aaron,

did you find a solution ?

[afaulsti]

Posted on May 17, 2011 at 13:56

Can you be more specific about this? I downloaded codesourcery and copied arm-none-eabi-objcopy.exe into a new folder. Then, I put my .elf file in the folder and ran:

arm-none-eabi-objcopy.exe -O ihex MyProject.elf

That changed the .elf file size, so I assume it converted. Then I renamed the .elf to .bin and tried programming it to the eval board. ST-Link Utility says that it programs and verifies, but the board itself is not executing the code. Resetting and power cycling don't help, though they do show that the original eval board code is no longer running. The code I'm trying to program works fine through the debugger, so I think I must be doing something wrong in this programming process. Any help would be greatly appreciated. I'm completely new to developing on ARM.