Yagarto vs Raisonance

[carl2399]

Posted on December 16, 2011 at 06:51

I'm using a makefile to build my application - I'm not a huge fan of IDE's.

By setting my PATH environment variable (in Win32 system) to the Raisonance toolchain everything builds fine and runs fine on my STM32F2.

By setting my PATH environment variable to the Yagarto toolchain everything builds fine (same errors and a very similar sized output) but the code does not run!

I do ''make clean, make all'' for both tests.

Put up here just in case somebody else wastes a day chasing their compiler in circles.

Yagarto is V4.6.0.

Raisonance is V4.3.2

 

[infoinfo989]

Posted on December 16, 2011 at 07:06

I must be missing the point here. Was there something attached to your post we're supposed to look at? Help with those errors you mentioned?

For what it's worth, I use the current version of Yagarto every day and am very happy with it.

~~~~~~~~~~~~~

http://www.frankvh.com/stm32-information.html

[rosarium]

Posted on December 16, 2011 at 09:04

do you have the patch files for STM32F2 for the debugger in place??

[carl2399]

Posted on December 16, 2011 at 09:49

I'm not sure what code to post. The code is about 10k lines. The code compiles fine (and with the same compiler error messages) in both compilers. I don't make any changes to either the makefile or any of the source.

End result: Raisonance code runs, Yagarto code hangs. And I have no idea why.

[carl2399]

Posted on December 16, 2011 at 09:50

I don't have the patch files for STM32F2 with the debugger in place, but then again I don't have a debugger.

[emalund]

Posted on December 16, 2011 at 15:41

same errors and a very similar sized output but the code does not run.

ifv you are using software that generates ''oadable code when there are errors, throw it away.

Erik

[Tesla DeLorean]

Posted on December 16, 2011 at 16:33

10K lines of code, and no debugger, trying to decide if that is brave or foolish. But made me chuckle this morning, so points for that.

The use of an objdump disassembly might shed some light on what's going pear shaped with the compiler/linker. If it's pulling in some ARM (32-bit) code via libraries, or compiling some, that'll get you a Hard Fault for sure.

[infoinfo989]

Posted on December 16, 2011 at 21:49

Well, if I were a betting man (which I'm not really), I'd be betting the reason one compiler produces running code and other doesn't, is because there's a bug (or more than one bug) in your code.

For quite some time I'd been building code using -O0 (no optimisations), because when I built using -O2 the executable would no longer run. Of course I blamed the compiler. Stupd compiler optimiser doesn't work, piece of junk, blah blah blah.

One day I got tired of it and decided to find out what was wrong. So I built using -O2, the code didn't run, and I debugged it. And I found this:

http://blog.frankvh.com/2011/09/04/stm32f2xx-sdio-sd-card-interface/

The bottom one in the list: SD_SendSDStatus() function

Yep, I found a bug in the ST-supplied code. They declared an array, then their function wrote 4 times as much data as that array could hold, with the predictable result that other variables etc in the RAM were being stomped on. For whatever reason, building with -O0 didn't really show this problem up, but -O2 did.

So if I were a betting man, I'd bet you've got code problems, not compiler problems. But that's just my guess.

[Andrew Neil]

Posted on December 16, 2011 at 22:56

''The code compiles fine ... with ... compiler error messages''

Eh??!!

Surely, ''compiles fine '' and ''with ... compiler error messages'' are mutually exclusive?!

[carl2399]

Posted on December 17, 2011 at 02:43

Thanks all for the responses!

I think Clive may have hit the nail on the head. I'm not intentionally using anything other than Thumb code, and I'm not sure which Yagarto library function (?) is being called as ARM

As to ''errors'', I should have said ''warnings''. I have 3 warnings, but they're all the same. ''warning: cast increases required alignment of target type''. They're all part of the SD card code, inSD_SendSDStatus as Frank mentioned as well as in the DMA setup routines. The code is correct, but I haven't figured out how to suppress the warning.

I always compile with -O2, because I've found it to be less tolerant of sloppy code, which in my opinion is a good thing.

As to no debugger. I guess it's just what you get used to. I have a dedicated debug/programming port (USART 1), and supplement that with pin toggling and generous use of assert statements. It doesn't seem to have slowed me down too much over the years, and didn't stop me from doing this development on custom hardware (hopefully there's a picture attached).

I only went to the Yagarto compiler as I wanted to start using some C++ code, but the Raisonance compiler had a linker error when adding __libc_init_array into the startup code. (Which I believe is used to initialise static objects). I've now found a workaround which achieves the same result without requiring__libc_init_array and which works with the Raisonance compiler.

________________

Attachments :

K1.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HtZb&d=%2Fa%2F0X0000000aRt%2F.uZaNp3mPKh1dyB6Ed79vOG2Xrq8N8Gq.N_ej.iYYwU&asPdf=false

[Tesla DeLorean]

Posted on December 17, 2011 at 18:46

As to no debugger. I guess it's just what you get used to. I have a dedicated debug/programming port (USART 1), and supplement that with pin toggling and generous use of assert statements. It doesn't seem to have slowed me down too much over the years, and didn't stop me from doing this development on custom hardware (hopefully there's a picture attached).

I'm certainly not discounting that as a method, I tend to use the serial port and heavily instrument code so I can understand what's happening in real time, and I understand the flow I'm expecting. But the JTAG comes in very useful on occasion, and saves a lot of time, trace can be useful too, but usually as a desperation play.