Compiles with arm-none-eabi-gcc 7.3.1 on ubuntu, but hangs when run

[danngreen]

On Ubuntu 16.04, using gcc-arm-embedded from ppa:team-gcc-arm-embedded/ppa (version 7.3.1), the code compiles without issues.

The bootloader appears to work fine, but the main app hangs immediately upon being started from the bootloader.

The issue appears with commit 39d6fab
Commits before this seem to be working OK.

[danngreen]

Thanks @forestcaver for reporting this

[tsointsoin]

@danngreen Is there any solution for this issue ? I just stumbled upon it.

[danngreen]

I created a vagrant based virtual machine, that works when compiling. It uses gcc-arm 8.2.1. Apparently the order of the objects when linked can cause the issue. Which is odd because there is never a compile or link error, just a runtime error. The runtime error appears to be that the I2C bus does not respond when initializing the PWM LED drivers.

You'll need vagrant installed, and VirtualBox (or similar)

Here it is, instructions are in the README:
https://github.com/4ms/4ms-dev-env

@tsointsoin @forestcaver If you have a chance to try this, can you let me know if this works for you?

[tsointsoin]

Thank you so much. It works for me, from within the Vagrant VM. Also I could compile and run my code with gcc-arm-none-eabi=15:8-2019-q3-1 using your new Makefile within my own system (Debian SID) which was not working before. The Swan boots and seems to be fully functional but the generated wavefile doesn't have the same length (Vagrant : 15982340 bytes / Debian : 15981980 bytes) for the same code.

[danngreen]

Great! Glad it works for you too.
The size difference is probably due to small variations in how gcc-arm 8-2019-q3 and gcc-arm 8-2019-q4 optimize the code.

[danngreen]

Got to the bottom of this! Thanks @LnnrtS for your help
The linker script was allowing the const data (.rodata section) get loaded at the wrong address. The ld linker increments the LMA and VMA counters separately, and there are apparently some situations in which it'll discard data from one but not the other. The result is that the difference between them is not constant. This of course wrecks havoc when the code expects a static variable to be found at one location, but some other data is there instead. The gnu ld linker has a flag ALIGN_WITH_INPUT which forces the LMA and VMA to stay in sync (constant difference). Adding this flag to the .rodata section fixes the issue.

The SWN can now be compiled with the latest arm-none-eabi toolchain (v10.3.1).

Background: the SWN runs code from FLASH by utilizing the prefetch and ART accelerators via the ITCM port. However this bus doesn't allow writing to the FLASH memory. So when you "flash" the SWN, the firmware file must be loaded via the AXI port to reach the FLASH memory. The AXI bus is accessed using addresses starting with 0x08000000. The ITCM port uses addresses starting with 0x00200000. So in order to do this, the SWN code is linked using load addresses (LMA) starting at 0x08000000 and run-time addresses (VMA) starting at 0x00200000. Since 0x0800'0000 + X is physically the same piece of memory as 0x0020'0000 + X (just accessed via a different port), the linker must strictly keep the load and runtime addresses in sync. I'm still not sure why the linker got out of sync (or on a deeper level: why it's even allowed to let these get out of sync), but the flag fixes it.