malloc causes hard fault on Cortex M0

Asked by Toon

Hi,

I'm currently developing an application on the Nuvoton NANO120LE3BN Cortex M0 Chip. While changing the application's source code to a newer version I started noticing that I was getting hard faults. I then upgraded my binary packaged compiler (for linux) version from 4_9-2015q3 to 5_4-2016q2 which made the hard fault even easier to cause.

Once the source code causes the error to occur, it keeps happening after resets or recompilations. By modifying small things (no memset call, less malloc size request) it was sometimes possible to have a 'functioning' firmware.

I've then created a new minimalist project that makes this issue very easily reproducible.
Attached are both a q2 and q3 project, with gdb output (in error_log) at time of hard fault, the source code, makefile, linker script, gdbinit script, and binaries. The exact instruction causing the hard fault has been marked (in this case it seems that the malloc code is trying to store something in the flash section of this chip), in some other scenario I also had hard faults caused by unalligned memory access (changing one of the workregisters value to a 4 byte alligned value prevented the hard fault from happening at that moment). All of this seems to me that it could be caused by memory corruption, allthough that seems hard with so few code?

One thing to mention: This chip has 16K of RAM, and I'm only allocating a couple of bytes: so I should not reach the memory limits at all. It also has 123K of flash (not 128 which is sometimes confusing).

archive compiled with q2 compiler: http://phalox.be/files/simple_project_q2.zip
archive compiled with q3 compiler: http://phalox.be/files/simple_project_q3.zip

- release version: Very much confirmed on 5_4-2016q2 and 5_4-2016q3
- whether the toolchain was rebuilt or you are using or binary package: binary package
- host machine: Linux mint RELEASE=17.1 CODENAME=rebecca EDITION="Cinnamon 64-bit"
- error/warning message encountered: none

I've been spending more than a week trying to figure things out but I'm totally stuck. It would be great if someone could help debugging my issue here.

Question information

Language:
English Edit question
Status:
Solved
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Solved by:
Andre Vieira
Solved:
Last query:
Last reply:
Revision history for this message
Best Andre Vieira (andre-simoesdiasvieira) said :
#1

Hi Toon,

I can't reproduce the failure you mention with your binary. The first malloc returns a pointer to: 0x200008a8 which is inside the ram's boundary. Are you sure you have the right memory mapping in your linker file?

The one you sent says ram starts at 0x20000000.

I'll see if I can think of something to help you in your debugging here. Though without being able to reproduce it on my end it becomes a lot more difficult to help.

Regards,
Andre

Revision history for this message
Toon (phalox) said :
#2

Hi Andre,

I think we have just discovered the solution! We believe that the __etext pointer set by the linker script, was set incorrectly (should have been defined after all the sections in flash). I still have to confirm but it looks promising.

I'll come back here to confirm! Thanks a lot for your input

Toon