I really don’t know what to do about this cleanly. Both files should NOT be edited, but they conflict.
d:\gcc\bin…/lib/gcc/arm-none-eabi/4.2.1/…/…/…/…/arm-none-eabi/include/stdint.h:84:
‘uint32_t’ has a declaration as ‘typedef long unsigned int uint32_t’
D:\MF\client_v4_2_comm\DeviceCode\include/tinyhal_types.h:60:
‘UINT32’ has a previous as ‘typedef unsigned int UINT32’
One INT32 is INT, the other INT32 is LONG. Needless to say, this causes problems.
Is this a different GCC version than what I show in the book?
Same one:
[quote]gcc.exe (CodeSourcery Sourcery G++ Lite 2007q3-53) 4.2.1
Copyright © 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.[/quote]
Then why I can compile hydra just fine with GCC, or any other project for this matter?
Some of the cortex files is pulling in some extra headers?
Possibly because there are a few layers of abstraction built into GCC. I suspect that something gets messed up somewhere… This is the definition of int32_t out of the GCC headers:
/* Check if "long" is 64bit or 32bit wide */
#if __STDINT_EXP(LONG_MAX) > 0x7fffffff
#define __have_long64 1
#elif __STDINT_EXP(LONG_MAX) == 0x7fffffff && !defined(__SPU__)
#define __have_long32 1
#endif
#if __have_long32
typedef signed long int32_t;
typedef unsigned long uint32_t;
#define __int32_t_defined 1
#elif __STDINT_EXP(INT_MAX) == 0x7fffffffL
typedef signed int int32_t;
typedef unsigned int uint32_t;
#define __int32_t_defined 1
#elif __STDINT_EXP(SHRT_MAX) == 0x7fffffffL
typedef signed short int32_t;
typedef unsigned short uint32_t;
#define __int32_t_defined 1
#elif __STDINT_EXP(SCHAR_MAX) == 0x7fffffffL
typedef signed char int32_t;
typedef unsigned char uint32_t;
#define __int32_t_defined 1
#endif
GCC is messed up.
From Include\limits.h:
INT_MAX is 2147483647
LONG_MAX is 9223372036854775807
But only if the CPU is Alpha, Spark, Arch64 or SparkV9
Else LONG_MAX is 2147483647L
Thus INT and LONG is the same…
But the compiler can’t be sure, hence it throws toy.
Also, the Hydra code might be consistent.
The STM32 code mixes between int32_t and INT32.
The compiler complains when you try to assign an INT32 to an int32_t or vice versa…
Then we can modify the STM32 code. I would stay away from modifying the core but, for the poirt, I would be okay changing it anyway I see appropriate.
Ok, edited the USB driver for the STM32. Looks like they cut come code from somewhere and didn’t change the defs.
Was:
typedef struct
{
__IO uint32_t EPiR[8];
__IO uint32_t RESERVED0[8];
__IO uint32_t CNTR;
__IO uint32_t ISTR;
__IO uint32_t FNR;
__IO uint32_t DADDR;
__IO uint32_t BTABLE;
} USB_TypeDef;
typedef struct
{
uint32_t EP_BUF[7][32]; // 7 endpoint buffers (64 bytes)
struct {
uint32_t ADDR_TX;
uint32_t COUNT_TX;
uint32_t ADDR_RX;
uint32_t COUNT_RX;
} EP_BUF_DESC[7]; // 7 endpoint buffer descriptors
} USB_PMA_TypeDef;
Changed to:
typedef struct
{
__IO UINT32 EPiR[8];
__IO UINT32 RESERVED0[8];
__IO UINT32 CNTR;
__IO UINT32 ISTR;
__IO UINT32 FNR;
__IO UINT32 DADDR;
__IO UINT32 BTABLE;
} USB_TypeDef;
typedef struct
{
UINT32 EP_BUF[7][32]; // 7 endpoint buffers (64 bytes)
struct {
UINT32 ADDR_TX;
UINT32 COUNT_TX;
UINT32 ADDR_RX;
UINT32 COUNT_RX;
} EP_BUF_DESC[7]; // 7 endpoint buffer descriptors
} USB_PMA_TypeDef;
Now all code compiles, but still stuck at link phase. Still “file not found”.
That is good news!
What file is missing?
It is there. I can see it. In:
D:\MF\client_v4_2_comm\BuildOutput\thumb2\GCC4.2\le\FLASH\release\STM32Stamp\lib
I have the same on FEZ Hydra build, same file same location and using GCC!
Ok, the problem was a compound issue.
The msbuild thing doesn’t tell you what happened, only that a command failed. I then copy that command and execute it by hand to see the error message.
The link command can’t be executed from the solution folder, I had to CD to the build lib folder.
Secondly. The Microsoft.Spot.system.gcc.targets file lacked statements to set the path for GCC libs when using thumb2. It had this:
<GNU_LIB_DIR Condition="'$(INSTRUCTION_SET)'=='thumb'">$(GNU_TOOLS)\$(GNU_TARGET)\lib\thumb</GNU_LIB_DIR>
<GNU_LIBGCC_DIR Condition="'$(INSTRUCTION_SET)'=='thumb'">$(GNU_TOOLS)\lib\gcc\$(GNU_TARGET)\$(GNU_VERSION)\thumb</GNU_LIBGCC_DIR>
I added this:
<GNU_LIB_DIR Condition="'$(INSTRUCTION_SET)'=='thumb2'">$(GNU_TOOLS)\$(GNU_TARGET)\lib\thumb2</GNU_LIB_DIR>
<GNU_LIBGCC_DIR Condition="'$(INSTRUCTION_SET)'=='thumb2'">$(GNU_TOOLS)\lib\gcc\$(GNU_TARGET)\$(GNU_VERSION)\thumb2</GNU_LIBGCC_DIR>
Now it tries to link but I get crap loads of link errors. I’m trying to pipe the errors to a log file so I can look at them, but the normal “>log.txt” addition to the command line doesn’t work…
Lol, found the link problem. There is a CortexM3 file for interrupts. The whole file is surrounded by:
#ifndef __GNUC__
Need to port that, then we should have a full compile…
Try to stub all functions and see if it compiles before you make changes. You do not have to use NETMF stubs, just copy/paste the same functions and empty them out fro GCC.
@ Errol Looks like you have made a lot of progress! Nice. What is you $(GNU_VERSION)?
@ Architect,
Don’t know how to get that. But I have this: http://www.tinyclr.com/forum/20/4691/#/3/msg45253
One more link error:
Quite frankly don’t know where that should be coming from…
Errol, you’re an inspiration to us all!
FWIW, this is one of my frustrations with C. Long, complicated mazes of #includes and typedefs that are nearly impossible to sort out. It’s not the languages fault, and it’s a function of it’s portability, but still.
@ Errol Ok. I see, so it is 4.2.1.
I am not far behind you. 4 compile errors. I am testing 4.5.1 though.
Errol,
Interrupts vectors should be in hardware specific startup template.
ST does not provide examples on GCC at least I couldnt find it except on CMIS library, where they put a GCC example that defines the startup sequence and the interrupt vectors.
Its located on:
STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/ST/STM32F4xx/Source/Templates/gcc_ride7
Its a new version of the discovery examples.
Hope it helps. I will try install everything tonigth if I had time and help you with it. I dont know If I could find time to do it because my son is sick… By the way I receive my kit yersterday, and its great but it would be better to have female headers instead of the ones they put on the board…