Porting over a project from Atmel Studio 7 to VIM (makefiles etc).

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

This is my first post here so excuse me if this is not in the correct forum.

 

We have recently decided to move away completely from any Windows products within my company. As such, I am in the middle of trying to port over a few Atmel Studio 7 to my Ubuntu Mate 18.07.5 virtual machine. I need some assistance with interpreting what the output produced by Atmel Studio 7 is actually saying, how much of it is windows fluff and how much of it do I need for my Makefile on Linux?

 

I found the toolchains for linux on https://www.microchip.com/en-us/... . Do I even need them? My worry is that they don't seem to be regularly updated and I need the system to stay up-to-date with updates to gcc and other stuff. I need to compile with arm-none-eabi-gcc. If I install the required tools manually through the terminal on Linux, will I run into some weird bugs regarding compatibility with different versions? I was reading through the output and there's nothing that immediately jumps out at me that makes me think I need to get the toolchains from the microchip website. 

 

An extract from the output:

------ Rebuild All started: Project: LCD_init, Configuration: Debug ARM ------

Build started.

Project "LCD_init.cproj" (default targets):

Target "PreBuildEvent" in file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Avr.common.targets" from project "C:\Users\westman\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\home\stch\.ssh\boot_mcu_firmware\LCD_init\LCD_init.cproj" (target "Build" depends on it):

Task "Exec"

get_version_info.cmd > "C:\Users\westman\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\home\serstech\.ssh\boot_mcu_firmware\\LCD_init\src\git_version.h"

'git' is not recognized as an internal or external command,

operable program or batch file.

'git' is not recognized as an internal or external command,

operable program or batch file.

Done executing task "Exec".

Done building target "PreBuildEvent" in project "LCD_init.cproj".

Target "CoreBuild" in file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Compiler.targets" from project "C:\Users\westman\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\home\serstech\.ssh\boot_mcu_firmware\LCD_init\LCD_init.cproj" (target "Build" depends on it):

Task "RunCompilerTask"

Shell Utils Path C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils

C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils\make.exe all --jobs 2 --output-sync

Building file: ../src/ASF/sam0/drivers/port/port.c

Invoking: ARM/GNU C Compiler : 6.3.1

"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\arm\arm-gnu-toolchain\bin\arm-none-eabi-gcc.exe"  -x c -mthumb -D__SAML21E18B__ -DDEBUG -DBOARD=USER_BOARD -DARM_MATH_CM0PLUS=true -DSPI_CALLBACK_MODE=true -DSYSTICK_MODE -DUSART_CALLBACK_MODE=true -DI2C_MASTER_CALLBACK_MODE=true  -I"../src/ASF/common/boards" -I"../src/ASF/sam0/utils" -I"../src/ASF/sam0/utils/header_files" -I"../src/ASF/sam0/utils/preprocessor" -I"../src/ASF/thirdparty/CMSIS/Include" -I"../src/ASF/thirdparty/CMSIS/Lib/GCC" -I"../src/ASF/common/utils" -I"../src/ASF/sam0/utils/cmsis/saml21/include_b" -I"../src/ASF/sam0/utils/cmsis/saml21/source" -I"../src/ASF/sam0/drivers/system" -I"../src/ASF/sam0/drivers/system/clock/clock_saml21" -I"../src/ASF/sam0/drivers/system/clock" -I"../src/ASF/sam0/drivers/system/interrupt" -I"../src/ASF/sam0/drivers/system/interrupt/system_interrupt_saml21" -I"../src/ASF/sam0/drivers/system/pinmux" -I"../src/ASF/sam0/drivers/system/power/power_sam_l" -I"../src/ASF/sam0/drivers/system/power" -I"../src/ASF/sam0/drivers/system/reset/reset_sam_l" -I"../src/ASF/sam0/drivers/system/reset" -I"../src/ASF/common2/boards/user_board" -I"../src" -I"../src/config" -I"../src/ASF/sam0/drivers/port" -I"../src/ASF/sam0/drivers/sercom" -I"../src/ASF/sam0/drivers/sercom/spi" -I"../src/ASF/common2/services/delay" -I"../src/ASF/common2/services/delay/sam0" -I"../src/ASF/common/services/serial" -I"../src/ASF/sam0/drivers/sercom/usart" -I"../src/ASF/sam0/drivers/sercom/i2c" -I"../src/ASF/sam0/drivers/sercom/i2c/i2c_sam0"  -O1 -fdata-sections -ffunction-sections -mlong-calls -g3 -Wall -mcpu=cortex-m0plus -c -pipe -fno-strict-aliasing -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror-implicit-function-declaration -Wpointer-arith -std=gnu99 -ffunction-sections -fdata-sections -Wchar-subscripts -Wcomment -Wformat=2 -Wimplicit-int -Wmain -Wparentheses -Wsequence-point -Wreturn-type -Wswitch -Wtrigraphs -Wunused -Wuninitialized -Wunknown-pragmas -Wfloat-equal -Wundef -Wshadow -Wbad-function-cast -Wwrite-strings -Wsign-compare -Waggregate-return  -Wmissing-declarations -Wformat -Wmissing-format-attribute -Wno-deprecated-declarations -Wpacked -Wredundant-decls -Wnested-externs -Wlong-long -Wunreachable-code -Wcast-align --param max-inline-insns-single=500 -MD -MP -MF "src/ASF/sam0/drivers/port/port.d" -MT"src/ASF/sam0/drivers/port/port.d" -MT"src/ASF/sam0/drivers/port/port.o"   -o "src/ASF/sam0/drivers/port/port.o" "../src/ASF/sam0/drivers/port/port.c"

Finished building: ../src/ASF/sam0/drivers/port/port.c

blahblahblah a bunch of other similar statements

 

Building target: LCD_init.elf

Invoking: ARM/GNU Linker : 6.3.1

"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\arm\arm-gnu-toolchain\bin\arm-none-eabi-gcc.exe" -o LCD_init.elf  src/ASF/common2/services/delay/sam0/systick_counter.o src/ASF/sam0/drivers/port/port.o src/ASF/sam0/drivers/sercom/i2c/i2c_sam0/i2c_master.o src/ASF/sam0/drivers/sercom/i2c/i2c_sam0/i2c_master_interrupt.o src/ASF/sam0/drivers/sercom/sercom.o src/ASF/sam0/drivers/sercom/usart/usart.o src/ASF/sam0/drivers/sercom/usart/usart_interrupt.o src/rvver.o src/ASF/sam0/drivers/sercom/spi/spi.o src/ASF/sam0/drivers/sercom/spi/spi_interrupt.o src/ASF/sam0/drivers/sercom/sercom_interrupt.o src/ASF/common2/boards/user_board/init.o src/ASF/common/utils/interrupt/interrupt_sam_nvic.o src/ASF/sam0/drivers/system/clock/clock_saml21/clock.o src/ASF/sam0/drivers/system/clock/clock_saml21/gclk.o src/ASF/sam0/drivers/system/interrupt/system_interrupt.o src/ASF/sam0/drivers/system/pinmux/pinmux.o src/ASF/sam0/drivers/system/system.o src/ASF/sam0/utils/cmsis/saml21/source/gcc/startup_saml21.o src/ASF/sam0/utils/cmsis/saml21/source/system_saml21.o src/ASF/sam0/utils/syscalls/gcc/syscalls.o src/main.o   -mthumb -Wl,-Map="LCD_init.map" --specs=nano.specs -Wl,--start-group -larm_cortexM0l_math -lm  -Wl,--end-group -L"../src/ASF/thirdparty/CMSIS/Lib/GCC"  -Wl,--gc-sections -Wl,-section-start=.text=0x6100  -mcpu=cortex-m0plus -Wl,--entry=Reset_Handler -Wl,--cref -mthumb -T../src/ASF/sam0/utils/linker_scripts/saml21/gcc/saml21e18b_flash.ld

Finished building target: LCD_init.elf

In the first part there are a whole bunch of includes to things that I am embarrassed to say I don't know what they are for. Do I truly need all of that or is Atmel Studio including a bunch of bloat?

 

The second part that builds the .elf file is more clear to me, here I presume I only need to change the path in the Makefile into something appropriate?

 

Interpreting the building of LCD_init.elf:

What is the -L"../src/ASF/thirdparty/CMSIS/Lib/GCC" for? Is it something that is included in gcc or is it some Atmel Studio weirdness?

 

Treat me like a noob, because I am.

 

//J

1010001010111101110111

Last Edited: Thu. Apr 8, 2021 - 07:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I would get your toolchain from Microchip as a .tar.gz. Sure it isn't the "latest" but 5.4 is nicely stable.

 

As for Makefiles the fact is that AS7 works that way anyway. If you have your project files in "dir" then when you Build within AS7 it creates dir\Debug\Makefile (or dir\Release\Makefile) so you can literally just lift a copy if that file and use it in Linux. Of course the fact it was in dir\Debug or dir\Release means that all file references ar to "../*" which means that to reuse it you will also need to put it in a sub directory of "dir" on the Linux system.

 

HOWEVER there is a MUCH simpler solution. Since Microchip took over Atmel they have been developing their own IDE (MPLABX) alongside Atmel/Microchip Studio 7 and unlike AS7 it is both Windows and Linux. So for an easy life just get the Linux version if MPLABX that has AVR support.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
for an easy life just get the Linux version if MPLABX that has AVR support.

+1

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Welcome!

Mithrandir_ wrote:
Do I even need them?
No

Mithrandir_ wrote:
I need to compile with arm-none-eabi-gcc.
Arm's GCC is popular.

Mithrandir_ wrote:
I was reading through the output and there's nothing that immediately jumps out at me that makes me think I need to get the toolchains from the microchip website.
From the ones at Microchip are device packs (I/O descriptors, linker options) and tool packs (debugger firmware)

Mithrandir_ wrote:
Treat me like a noob, because I am.
... or not ... you Vim operatorwink

 


GNU Toolchain – Arm Developer

 

Atmel Packs (Microchip Studio)

Microchip Packs Repository (MPLAB X)

 

There's a plethora of editors; one of many :

UltraEdit | The world's best text editor due to UltraEdit / UltraStudio as an alternative to MPLAB-X? | Microchip

 

edit : typo

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Thu. Apr 8, 2021 - 03:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mithrandir_ wrote:
I need to compile with arm-none-eabi-gcc.

But you're posting in the AVR section?

 

EDIT

 

But MPLAB-X also supports the SAM devices - so that recommendation still stands.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Thu. Apr 8, 2021 - 05:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First of all, thank you all very much for the help.

 

clawson wrote:

Yes, I would get your toolchain from Microchip as a .tar.gz. Sure it isn't the "latest" but 5.4 is nicely stable.

 

Would you say that 5.4 is OK to use in production level code? I suppose since Atmel Studio 7 uses it, it ought to be fine since that is what we're using to build the project right now.

 

Quote:

As for Makefiles the fact is that AS7 works that way anyway. If you have your project files in "dir" then when you Build within AS7 it creates dir\Debug\Makefile (or dir\Release\Makefile) so you can literally just lift a copy if that file and use it in Linux. Of course the fact it was in dir\Debug or dir\Release means that all file references ar to "../*" which means that to reuse it you will also need to put it in a sub directory of "dir" on the Linux system.

Yes indeed, I did find the Makefile in there, however, it contains a bunch of windows paths. That is what led me to suspect that there was some kind of bloating going on, surely this little application can't need all that stuff? But maybe it does. I'm by not means an expert on embedded development (yet smiley ).

 

So the way that the project directory looks right now in Windows is a folder called "LCD_init", a subfolder in there is called "Debug" and that's where I found the Makefile. I would like to replicate this folder system and compilation process on my Linux machine.

 

So for an example, if we just look at a random include like  -I"../src/ASF/sam0/utils/cmsis/saml21/source" . I assume that I can either take these files and move them to a different folder and then change the path, or do I need to create some kind of folder system that makes Linux find these applications where they are supposed to be? Suppose that I want them in a generic place so that they aren't tied just to this code, but that they can be used generally as in Atmel Studio 7 for any future code. Does the .tar.gz file automatically put things where they need to go? Where do I unzip it, in ~, in root? Or do I have to manually place each file where it needs to go?

 

It can't really be as easy as unzipping the tar file in my home directory, can it? (please Lord let it be that simple!)

 

Quote:

HOWEVER there is a MUCH simpler solution. Since Microchip took over Atmel they have been developing their own IDE (MPLABX) alongside Atmel/Microchip Studio 7 and unlike AS7 it is both Windows and Linux. So for an easy life just get the Linux version if MPLABX that has AVR support.

 

I looked at the IDE and it seems exactly like the kind of annoying bloatware that I am trying to get rid of. I don't want to be negative Nancy over here but I really dislike it and would much rather figure out a workaround that allows me the control that I have through just working in a Linux terminal. Again, I don't want to be negative nor do I want to seem like I am dismissing your advice, but I am ready to go through some headache to get this working without an IDE. I love how clean it is to work in the terminal and how much in control I feel over the whole process. I also feel like it makes me a better programmer as I get a much better understanding of what I am doing instead of black-box engineering by pressing some magic button on an IDE.

 

 

 

 

gchapman wrote:

Welcome!

 

Thank you!

 

Quote:

Mithrandir_ wrote:

I was reading through the output and there's nothing that immediately jumps out at me that makes me think I need to get the toolchains from the microchip website.

From the ones at Microchip are device packs (I/O descriptors, linker options) and tool packs (debugger firmware)

 

Ah I see, I see. So theoretically I could compile and run everything without any of that stuff. Suppose, however, that I want to have access to it all, I assume that it is included in the toolchains for Linux?

 

Quote:

Mithrandir_ wrote:

Treat me like a noob, because I am.

... or not ... you Vim operatorwink

 

I have a working knowledge of programming but I'm fairly new to embedded systems. I've only ever dabbled in it before :). Thanks for the vote of confidence though, haha.

 

 

awneil wrote:
But you're posting in the AVR section?

 

Yes, sorry about that. However after a titanic amount of googling I kept ending up on these forums. Granted, the questions where about porting avr-gcc to Linux but my assumption is that it shouldn't be much different from porting arm-gcc as really the only thing that is different is the compiler. The "process" of porting to Linux ought to be similar, or am I wrong? My logic is that really what it comes down to is moving a makefile, making sure that it works and then making sure that a bunch of dependencies that are used in the compilation process exist on the system.

 

1010001010111101110111

Last Edited: Thu. Apr 8, 2021 - 06:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

An IDE makes it much easier to just get on and write microcontroller code without a lot of faffing about. Sure it may be "bloaty" but in these days of Terabyte sized drives who actually cares?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mithrandir_ wrote:
Suppose, however, that I want to have access to it all, I assume that it is included in the toolchains for Linux?
No

Another source is Arm (CMSIS)

CMSIS | CMSIS Search – Arm Developer

enter the MCU's part number, result is https://developer.arm.com/embedded/cmsis/cmsis-packs/devices/Microchip/ATSAML21E18B

.atpack is a zip that's chock full of headers

 

MPLAB X tool packs won't be required in this case (no IDE) as Arm debuggers are numerous.

Firmware for CoreSight Debug Access Port (CMSIS-DAP)

GitHub - mbedmicro/pyOCD: Open source python library for programming and debugging ARM Cortex-M microcontrollers using CMSIS-DAP

Mithrandir_ wrote:
... but I'm fairly new to embedded systems. I've only ever dabbled in it before :).
Welcome to the deep endwink

 

P.S.

Mithrandir_ wrote:
... but I am ready to go through some headache to get this working without an IDE.
Embedded systems design is easier by an IDE.

There are mid-weight and light-weight IDE.

One of several (many?) GPLv3 IDE :

What is GNAT Studio?

GNAT Studio Tutorial — GNAT Studio Tutorial via Documenation | Commercial software solutions for Ada, C and C++ | AdaCore

Otherwise, consider ctags :

Home · Universal Ctags

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mithrandir_ wrote:
clawson wrote:

Yes, I would get your toolchain from Microchip as a .tar.gz. Sure it isn't the "latest" but 5.4 is nicely stable.

Would you say that 5.4 is OK to use in production level code?

When he said that, clawson was referring to the AVR toolchain.

 

I looked at the IDE and it seems exactly like the kind of annoying bloatware that I am trying to get rid of.

So do you want to focus on being an expert in setting up build systems, or do you want to focus on developing embedded code?

 

Drive space is virtually free, but your time is expensive ...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
No

 

Another source is Arm (CMSIS)

CMSIS | CMSIS Search – Arm Developer

enter the MCU's part number, result is https://developer.arm.com/embedded/cmsis/cmsis-packs/devices/Microchip/ATSAML21E18B

.atpack is a zip that's chock full of headers

 

MPLAB X tool packs won't be required in this case (no IDE) as Arm debuggers are numerous.

Firmware for CoreSight Debug Access Port (CMSIS-DAP)

GitHub - mbedmicro/pyOCD: Open source python library for programming and debugging ARM Cortex-M microcontrollers using CMSIS-DAP

 

Ah I see, now I get it. Thank you! 

 

awneil wrote:
So do you want to focus on being an expert in setting up build systems, or do you want to focus on developing embedded code?

 

Well right now my job IS to set up a custom build system - I was handed this project by my boss. We already compile everything else through makefiles. This is a small booting application that is needed to start our LCD screen - we would like to be able to compile it through the terminal like we do with everything else. The goal is then to add it to the shell script that compiles the entire system so that we won't need to do two different manual compilations. 

 

At any rate, I went ahead and installed the bloatware for now. I can use it and lift the makefile straight out of the IDE and get it working that way, I suppose. However, when I built my HEX file and flashed it to memory it actually killed the device. I had to hardware-reset everything back to zero. Opening up the hex files I noticed some immediate differences:

 

Correct

:10610000A8250020D97B0000D57B0000D57B0000AE :10611000000000000000000000000000000000007F

Incorrect

:10000000A8250020D1180000CD180000CD18000050 :1000100000000000000000000000000000000000E0

 

I suppose maybe I should compile the assembly file and see what the heck is going on, but I'm not sure how to do that in Atmel Studio 7 or MPLABX - yet another reason for why I hate IDEs :(. 

 

Nevermind, I was able to solve the issue. Now I will extract the Makefile and see about compiling manually.

 

1010001010111101110111

Last Edited: Fri. Apr 9, 2021 - 11:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is really strange. With all the same compiler options, the exact same build order, the same version of arm-none-eabi-gcc the project build works on Atmel Studio 7 and the device boots normally, but it fails to boot and gets stuck on loading with MPLABX.... I'm at a loss. I would really like to have a look at the .S files to see what is going on - and here we run into the massive problem with IDEs. How the heck do I do that? I've done some googling and I can't really find an answer to my problem. I don't want the .lss file, I want the pure .S file.

1010001010111101110111

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Compiled in Atmel Studio 7:

Disassembly of section .text:

00006100 <exception_table>:
    6100:	a8 25 00 20 d9 7b 00 00 d5 7b 00 00 d5 7b 00 00     .%. .{...{...{..
	...
    612c:	d5 7b 00 00 00 00 00 00 00 00 00 00 d5 7b 00 00     .{...........{..
    613c:	25 81 00 00 d5 7b 00 00 d5 7b 00 00 d5 7b 00 00     %....{...{...{..
    614c:	d5 7b 00 00 d5 7b 00 00 d5 7b 00 00 d5 7b 00 00     .{...{...{...{..
    615c:	d5 7b 00 00 65 78 00 00 75 78 00 00 85 78 00 00     .{..ex..ux...x..
    616c:	95 78 00 00 a5 78 00 00 b5 78 00 00 d5 7b 00 00     .x...x...x...{..
    617c:	d5 7b 00 00 d5 7b 00 00 d5 7b 00 00 d5 7b 00 00     .{...{...{...{..
	...
    6194:	d5 7b 00 00 d5 7b 00 00 d5 7b 00 00 d5 7b 00 00     .{...{...{...{..
    61a4:	d5 7b 00 00 d5 7b 00 00 d5 7b 00 00 00 00 00 00     .{...{...{......

 

Compiled in MPLABX:

Disassembly of section .text:

00006100 <_sfixed>:
    6100:	200025a8 	.word	0x200025a8
    6104:	00007c25 	.word	0x00007c25
    6108:	00007c21 	.word	0x00007c21
    610c:	00007c21 	.word	0x00007c21
	...
    612c:	00007c21 	.word	0x00007c21
	...
    6138:	00007c21 	.word	0x00007c21
    613c:	00008179 	.word	0x00008179
    6140:	00007c21 	.word	0x00007c21
    6144:	00007c21 	.word	0x00007c21
    6148:	00007c21 	.word	0x00007c21
    614c:	00007c21 	.word	0x00007c21
    6150:	00007c21 	.word	0x00007c21
    6154:	00007c21 	.word	0x00007c21
    6158:	00007c21 	.word	0x00007c21
    615c:	00007c21 	.word	0x00007c21
    6160:	00007921 	.word	0x00007921
    6164:	00007931 	.word	0x00007931
    6168:	00007941 	.word	0x00007941
    616c:	00007951 	.word	0x00007951
    6170:	00007961 	.word	0x00007961
    6174:	00007971 	.word	0x00007971
    6178:	00007c21 	.word	0x00007c21
    617c:	00007c21 	.word	0x00007c21
    6180:	00007c21 	.word	0x00007c21
    6184:	00007c21 	.word	0x00007c21
    6188:	00007c21 	.word	0x00007c21
	...
    6194:	00007c21 	.word	0x00007c21
    6198:	00007c21 	.word	0x00007c21
    619c:	00007c21 	.word	0x00007c21
    61a0:	00007c21 	.word	0x00007c21
    61a4:	00007c21 	.word	0x00007c21
    61a8:	00007c21 	.word	0x00007c21
    61ac:	00007c21 	.word	0x00007c21
    61b0:	00000000 	.word	0x00000000

 

Why are they different?! I've checked all the options they are the same, the compiler versions are identical. What the heck is going on!? The MPLABX code does NOT work.

 

The functions seem to be doing the same thing but mapped to different points in memory, the MPLABX file is about 1kB larger than the Atmel Studio file for some mysterious reason.

Atmel Studio:

void cpu_irq_enter_critical(void)
{
	if (cpu_irq_critical_section_counter == 0) {
    78c4:	4b0c      	ldr	r3, [pc, #48]	; (78f8 <cpu_irq_enter_critical+0x34>)
    78c6:	681b      	ldr	r3, [r3, #0]
    78c8:	2b00      	cmp	r3, #0
    78ca:	d106      	bne.n	78da <cpu_irq_enter_critical+0x16>
 */

MPLABX:

void cpu_irq_enter_critical(void)
{
	if (cpu_irq_critical_section_counter == 0) {
    6268:	4b0c      	ldr	r3, [pc, #48]	; (629c <cpu_irq_enter_critical+0x34>)
    626a:	681b      	ldr	r3, [r3, #0]
    626c:	2b00      	cmp	r3, #0
    626e:	d106      	bne.n	627e <cpu_irq_enter_critical+0x16>
 */

 

1010001010111101110111

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For future reference the problem in this case was with the UART protocol coming from the SAML21. It was not being properly initialized. After having re-written some code to include delays to wait for the UART communication the code compiled and ran on the board without any issues. I2C and SPI communication did not encounter any problems. Still not sure exactly WHAT is going on with the UART but it seems to take a while longer (half a second) to start for whatever reason. 

 

After that I simply pulled the makefiles out of the MPLABX directory, changed some paths and I am now able to compile everything manually. 

1010001010111101110111