Toolchain release notes

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

Is there release notes somewhere that would tell me what changed between different versions of the GCC toolchain?

In particular, I'm looking for changes between the following two toolchains:

arm-none-eabi-gcc (crosstool-NG 1.19.0 - Atmel build: 277) 4.8.3 20131129 (release) [ARM/embedded-4_8-branch revision 205641]

arm-none-eabi-gcc (Atmel build: 371) 4.8.4 20140725 (release) [ARM/embedded-4_8-branch revision 213147]

(I've been chasing a bug that felt like a hardware bug (an unexpected hard fault). My toolchain of choice was still 4.8.3.277. Then I decided to compile with a different toolchain. The bug went away. But then again, with the old toolchain, the bug was dependent on the code position - if things shifted slightly the bug would sometimes go away too. So, I want to make sure that the problem, whatever it was, really got fixed and ideally understand what the problem was in the first place.)

Eugene

Last Edited: Sun. Mar 5, 2017 - 02:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looking at the code differences. The old version versions generates something that is called "register_tm_clones". Of course, I have no idea what it is and what it does.

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

I keep falling into the same trap. "register_tm_clones" has nothing to do with anything. Just needed a little sleep. I need to drop the old toolchain! It is "ldr" instead of "ldrb", again.

Although I'm still a little bit unsure why "ldr" is a problem in this case, where it is used to read "NVMCTRL->INTFLAG.reg", which is a uint8_t register, but properly aligned on an uint32_t boundary. Not clear why that would result in a hard fault. Maybe I'll ask Atmel.

Last Edited: Sun. Mar 5, 2017 - 12:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For the record, here are the conditions when it hard faults:
- The micro is ATSAMD21G16B
- Right after erasing a row in the RWW section
- The "ldr" instruction itself is not uint32_t-aligned (i.e., ldrAddr%4=2)

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

ezharkov wrote:
I've been chasing a bug that felt like a hardware bug (an unexpected hard fault).

Note that a "Hard Fault" doesn't (necessarily) mean a hardware problem.

There is a good section on Hard Faults in Joseph Yiu's book:

The Definitive Guide to the ARM Cortex-M0 - 1st Edition - ISBN: 9780123854773, 9780123854780

https://www.elsevier.com/books/t...

 

See also: https://community.arm.com/iot/em...

 

 

 

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

""Hard Fault" doesn't (necessarily) mean a hardware problem" - I know that. But in this particular case it does feel like it is a hardware problem. I gave them (the Microchip support) is simple compilable example (with just a couple of ASF calls from main).