Porting code from IAR to TrueStudio

[allantommathew]

Posted on January 28, 2018 at 18:57

Hi,

I had been using IAR Embedded Workbench for programming and burning codes on STM32F7. Since the release of TrueStudio 9, I thought it would be wise to switch to a free version ahich has no code size limitations. Hence I installed and set up TrueStudio, created a new project, made initialization code with CubeMX (just like what I had done with IAR Embedded workbench) and copy-pasted my old code (the functional part) into the new project. After some editing I was able to compile the code and burn it. (I found the debugger not as smooth as the IAR one). The disappointment was when I discovered that the code, which was compiled and burned by IAR, works fine, but the one compiled and burned by TrueStudio, to the same hardware, doesn't work. (Note that the code and the hardware is the same).

Did I do something wrong? I have not worked with eclipse before. (To be honest, I was never successful in setting up the environment in eclipse). It would be good if someone could shed some light into this issue.

#workbench #truestudio-9.0 #truestudio-9 #truestudio #embedded #stm32f7 #stm #iar #stm32

[Tesla DeLorean]

Posted on January 28, 2018 at 20:34

More likely an issue with the compiler than the editor. Try different optimization levels, and look for code that might induce hazards.

Check that structures especially local/auto variables on the stack are properly initialized, and values that can change outside of program flow are identified as volatile.

Try to pin failure to specific pieces of code, and review that code as output by the compiler.

[AvaTar]

Posted on January 29, 2018 at 08:46

Try different optimization levels, and look for code that might induce hazards.

More precisely, I would try with optimization turned off.

In my experience, the IAR compiler is significantly better than the Atollic one.

Turn optimizations back on, and follow Clive's instruction.

Hence I installed and set up TrueStudio, created a new project,...

This usually means the IDE created a 'default' stack size for your project, which is another common problem.

[Andrew Neil]

Posted on January 29, 2018 at 13:22

copy-pasted my old code (the functional part) into the new project

So what about all the other project settings that are not part of the 'functional' code?

The 'metadata', if you like.

doesn't work

So this just becomes a standard debugging exercise, then:

You'll have to use the debugger, and/or instrument the code, to find out where, exactly, it does not work.

Step the code in both IAR and TrueStudio - and see where they diverge...

[allantommathew]

Posted on January 30, 2018 at 18:13

Thank you guys for the quick response.

More likely an issue with the compiler than the editor. Try different optimization levels, and look for code that might induce hazards.

Yes I too thought that it might be a settings issue with the compiler. Changing optimization level is indeed a good thing to start with.

More precisely, I would try with optimization turned off.

I turned off the optimization but still the code doesn't work.

This usually means the IDE created a 'default' stack size for your project, which is another common problem.

Yes you are right, I haven't changed the stack size of the project. It must be the default values of a project. To be honest I haven't worked with the stack size so I'm not sure about it. In the mean time I'll try to calculate the stack size.

[allantommathew]

Posted on January 30, 2018 at 19:09

So this just becomes a standard debugging exercise, then:

I'm sorry but I didn't understand what you had meant by this.

You'll have to use the

debugger, and/or instrument the code, to find out where, exactly, it does not work.

The debugger isn't working properly. After three-four steps the debugger throws as error.

Step the code in both IAR and TrueStudio - and see where they diverge.

I'll try doing this... but I'm not so sure about the TrueStudio debugging part. I'll take a screenshot of the debugger error maybe.

[Tesla DeLorean]

Posted on January 30, 2018 at 20:16

I think Andrew means 'doesn't work' is a bit nebulous, you need to use available means to narrow that down a bit more. This might mean using GPIO or USART to track how deeply into your code it is getting, and if it gets to places like the Hard Fault or Error Handler functions.

OpenOCD tends to be a little sketchy, and you might need to check for software updates or patches, or specific things you need to have in a debugger script. Worst case the ST-LINK Utilities do provide a method to step and debug code execution. There might be better tutorials and support from Atollic directly, check FAQ or forums, issues with debug pods seems to be a recurring topic.

[Andrew Neil]

Posted on January 30, 2018 at 21:16

Yes, that's exactly what I meant.

If you can't get the debugger to work in TrueStudio, it might be possible to use the IAR debugger to debug the executable from TrueStudio - ie, from GCC.

[henry.dick]

Posted on January 30, 2018 at 23:02

'

Did I do something wrong?'

there are innumerable reasons for that. the compilers are different, the settings could be different, libraries could be different, ....

you have to help others help you.

[Mattias Norlander1]

Posted on February 01, 2018 at 12:54

Hi atom,

When you generated the project for TrueSTUDIO you may have noticed that the default active build configuration 'Debug' uses optimization setting: -Os. This is not good. It means that the GCC compiler is allowed to optimize the C code so that it no longer has a 1-to-1 match with assembly instructions. The result is that when you try to step C statements in the debugger the instructions in the elf-file cannot be properly mapped to the C statements and it will appear as if the debugger is just jumping randomly in the C code. Is this what happened? If so just change the optimization level to -O0. Nevertheless this has been suggested earlier by other users in this thread. This has been bug reported to CubeMx-team.

A remark: TrueSTUDIO does not rely on OpenOCD. Instead it has its own proprietary ST-Link GDB-server. Problems found with the combinaion of ST-Link + OpenOCD is not necessarily a problem using TrueSTUDIO + ST-Link.

Have you been able to narrow down more precisely where the problem occurs?