error: reinterpret_cast from integer to pointer

[vaughanatworld]

I'm having problems compiling Motate on Ubuntu 64 and gcc-arm-none-eabi-6-2017-q2 with the following error:
../../motate/cmsis/TARGET_Atmel/sam3x/include/sam3x8e.h:500:21: error: reinterpret_cast from integer to pointer
It seems this is a pretty well documented issue (arm launchpad) but no simple solution is provided:
"References to memory mapped registers"
https://answers.launchpad.net/gcc-arm-embedded/+question/259010

It looks like the git cloned Motate used gcc-arm-none-eabi-5_4-2016q2 when last committed to github. This compiler also violates the new C language standard.

Given your on going work on g2core, you must have solved the problem. Can you share the solution?

Many thanks.
Brian

[vaughanatworld]

I just tried compiling g2 on the same machine with the same compiler. The same class of error is popping up on Motate.

[giseburt]

Did you try the branch sams70-port ? In g2 the relevant branch would be dev-168-gquintic.

[vaughanatworld]

The new git branches solve the compiler problems (Motate and g2core). Thank you.
In the Motate blink demo, there seems to be missing make files boards.mk and board/ArduinoDue.mk files or something equivalent. I am trying "make BOARD=Due". My messing about making up with my own mk files is not helping. Before investing a bunch of time, might you have a simple solution?
Many thanks
Brian

[giseburt]

I would recommend copying the ArduinoDue* files and directory from https://github.com/synthetos/g2/tree/dev-168-gquintic/g2core/board to a board directory in your own project, and use that. The .mk file in particular will need adjusted, but it should be fairly straightforward. The board files in Motate proper should probably be removed. They’re outdated, unfortunately. May I ask what project you’re using Motate for? I’d love to know if you can tell.

…

On Tue, Sep 26, 2017 at 7:26 PM vaughanatworld ***@***.***> wrote: The new git branches solve the compiler problems (Motate and g2core). Thank you. In the Motate blink demo, there seems to be missing make files boards.mk and board/ArduinoDue.mk files or something equivalent. I am trying "make BOARD=Due". My messing about making up with my own mk files is not helping. Before investing a bunch of time, might you have a simple solution? Many thanks Brian — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXj0WIf9jvmsyyo8bkuwYmZIGYVBzOzks5smZZNgaJpZM4Pkl9c> .

[vaughanatworld]

I'm retrofitting an old Phoenix GS to use g2core. I've built my own patch board to hook up a Due to the original Stepper controllers. When I started testing, (Atmel Studio 7 on Win 10 and Atmel ICE) none of the pins on the patch board wiggled but chilipeppr works..... so I decided to back up and try to try a blink program and test the hardware.

That took me to Motate and blink, then compile problems, mk file problems, interrupt not defined problems. Start over reread the documentation on Git. Build a vm ubuntu, clone Motate, encounter compiler errors, get help from you, get mk file problems, get help from you and I'm here now. Classic two steps forward and one step back. I learn something new for each step, regardless of the direction.

I know I could do the hardware test quickly with the Arduino IDE but then I would have missed learning an arm C/C++ development environment. If you have patience with me I'll get there eventually.
Regards
Brian

[vaughanatworld]

I have taken your advice and copied the board stuff from g2core.
However, I'm now encountering a link error with an undefined reference to '_write'.
It looks like something to do the the g2core json api. Blink doesn't need an api.... just yet.
I'll track this down in more detail in the morning.
Regards
Brian

[vaughanatworld]

Figured out the _write issue. For now set the linker flag: LDFLAGS += -specs=nosys.specs . This won't cut it when I get to g2core but is good enough for blink. In g2core do you use nano.specs? Did you add an _write stub?

My last problem is with execution of initialization code (not your stuff). In SamUniqueID.cpp -> UUID_t::UUID_t() -> line 90: uint8_t byte = (_d[i/4] >> (i%4)) & 0xF; -> memory access error exception.
The disassembly puts the exception on the assembler instruction ldr.w r2, [r3, r2, lsl #2] .

By fiddling with the OPTIMIZATION setting, I can always find at least one setting which will give proper execution. I have 2 different Atmel Studio solutions for the blink demo. Different OPTIMIZATION settings work for each setup. The good settings always work, build after build. The bad settings never work. The failure is always on the same ldr instruction. (The optimizer moves the ldr around a bit in the code).

Have you seen similar behavior during your exploits?
Many thanks
Brian

[justinclift]

@vaughanatworld How'd you go with this? 😄