Day #38 – Demo code is compiled and runs.

Posted on by crackingcontraptions_3voi0v

Today, I scratched around some more and finally decided I had to ask for help.  This was just soaking up a lot of time, doing random things that I thought might be the cause of the problem. i.e. not based on any real evidence.

So I tooled a message for David to send to Leo.

Thank heavens, that David had the good sense to read my drivel before he sent it.  It appears Leo actually sent us a revised IDE installation document last week.

Hi David
The attached Eclipse doc is the latest.
Is that not the one I gave you?
Regards,
Leo Theunissen

David figured, I hadn’t noticed it and sent me a nudge.   It’s not easy being so stupid.  What a waste of bloody time.
—————
So I printed off a new version of the document and carefully went through all the installation steps. It’s a lot, lot better, but there are still issues.

43 files compiled with mere warnings, but it finally ground to a halt with some “Assembler messages”.  Who knows what this means?

‘Building file: ../Libraries/CMSIS/CM3/CoreSupport/core_cm3.c’
‘Invoking: Cross ARM C Compiler’
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -w  -g3 -DSTM32F10X_CL -DUSE_STDPERIPH_DRIVER -I”C:UserslammingworkspaceDecaRangingMPEVBLibrariesSTM32F10x_StdPeriph_Driverinc” -I”C:UserslammingworkspaceDecaRangingMPEVBLibrariesSTM32F10x_StdPeriph_Driversrc” -I”C:UserslammingworkspaceDecaRangingMPEVBLibrariesCMSISCM3CoreSupport” -I”C:UserslammingworkspaceDecaRangingMPEVBLibrariesCMSISCM3DeviceSupportSTSTM32F10x” -I”C:UserslammingworkspaceDecaRangingMPEVBsrcapplication” -I”C:UserslammingworkspaceDecaRangingMPEVBsrccompiler” -I”C:UserslammingworkspaceDecaRangingMPEVBsrcdecadriver” -I”C:UserslammingworkspaceDecaRangingMPEVBsrcplatform” -I”C:UserslammingworkspaceDecaRangingMPEVBsrcsys” -std=gnu11 -MMD -MP -MF”Libraries/CMSIS/CM3/CoreSupport/core_cm3.d” -MT”Libraries/CMSIS/CM3/CoreSupport/core_cm3.o” -c -o “Libraries/CMSIS/CM3/CoreSupport/core_cm3.o” “../Libraries/CMSIS/CM3/CoreSupport/core_cm3.c”
C:UserslammingAppDataLocalTempccKeD9Ks.s: Assembler messages:
C:UserslammingAppDataLocalTempccKeD9Ks.s:772: Error: registers may not be the same — `strexb r3,r2,[r3]’
C:UserslammingAppDataLocalTempccKeD9Ks.s:818: Error: registers may not be the same — `strexh r3,r2,[r3]’
cs-make: *** [Libraries/CMSIS/CM3/CoreSupport/core_cm3.o] Error 1

Aha!  http://www.atollic.com/index.php/kb/1-kb_building/117-kb_error_in_strexb

In the tool chain included in TrueSTUDIO up to version 5.0 there where a bug in gcc for optimization level -O0 that would allow the code to compile with that optimization.
Hot to change to a lower optimization level for STREXB and STREX:
Find the functions __STREXB and STREXH. They are located in the CMSIS libraries. The exact position for the libraries depends on the project organization.
Change the function prototypes for these two function to set a lower optimization level with [optimize(“O0”)].
But I already have optimization “O0”  and the precise fix they recommend doesn’t match my source.
—————
So the software that they suggest you download from ST is out-of-date.  It seems pretty clear tome that nobody has run through the DW instructions.
I managed to find a more modern version out on the web.  

I downloaded it and patched in the new core_cm3.c and tried to rebuid.   Got exactly the same error.   This time I opened up the code and it seems to match the reported buggy code.  So I made the suggested alteration to the new code described here:  http://www.coocox.org/forum/topic.php?id=943

I think there is an error in core_cm3.c file at CoIDE 1.7.1.
I had the same issue with Sourcery CodeBench gcc 4.7.2 and it was resolved after editing cmsiscore_cm3.c file in my project’s directory.According to this thread you should edit functions __STREXB and __STREXH by changing “=r” to “=&r”.
You’ll see code:
__ASM volatile (“strexb %0, %2, [%1]” : “=r” (result) : “r” (addr), “r” (value) );
Should be:
__ASM volatile (“strexb %0, %2, [%1]” : “=&r” (result) : “r” (addr), “r” (value) );

I ended up with two edited lines in ___STREXB and __STREXH

(line 736) __ASM volatile (“strexb %0, %2, [%1]” : “=&r” (result) : “r” (addr), “r” (value) );
(line 753) __ASM volatile (“strexh %0, %2, [%1]” : “=&r” (result) : “r” (addr), “r” (value) );

I saved and recompiled.
Yay… it compiles now!

The important statistics we have been waiting to see are:

   text   data    bss    dec    hex filename
  67992   1552   4992  74536  12328 DecaRangingMPEVB.elf

  • text is basically the code that lives in flash.  Initializers for variables that live in RAM will be placed here too, but don’t contribute to the text size.
  • data is pre-initialized variables, that lives in RAM.  The initializers will be in flash, and will get copied to ram before the main routine is called.
  • bss is un-initialized variable storage that lives in RAM.
  • dec and hex are the total size of everything expressed in decimal and hex.  It’s not useful unless you are worried about storing/transmitting the image for subsequent download.

Yay… it downloads now.
Yay… it runs.

 

Leave a Reply