Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
I am trying to upload a simple program that does nothing to my samd51. Here is the code:
void main(){}
I have compiled it to the exact samd51 model I have using platformio. But when I telnet to OpenOCD and do a reset run, it halts saying that there is a Handler HardFault.
A minimal bare metal microcontroller program should contain at least this: an interrupt vector table. On SAMD and similar ARM, this is the boot area flash from address zero and beyond, which also contains the stack start address. As well as the address of the hardfault handler & friends, and of course every interrupt used, if any.
Usually this is solved by tool vendors in some specific way, through linker scripts or as part of the C run-time. If you aren't using a tool chain but just a "naked" compiler, you must manually generate the whole interrupt vector, fill it up with relevant information and make sure to download it into flash.
Additionally, in order to enable C programming, you must have a "C run-time" (CRT) library that sets up the various memory segments before it calls main(). On ELF-like linkers these are .bss and .data as a bare minimum. You also need to configure system clock, watchdog and other fundamental stuff early on, preferably from the reset vector. Some systems require MMU setup as well, but that shouldn't be necessary on Cortex M, from what I remember.
If you haven't got a clue about any these things, get a tool that does it for you.
There are many likely issues here, and probably more than one is an actual problem, though it's hard to guess which is first tripping the hard fault.
As explained by others, one cannot simply run C code on a bare target; startup code is needed, and on an ARM MCU that must begin with a vector table containing at least the entry address and the initial stack pointer value
Your main() returns, in an embedded setting that in and of itself could be a fault - typically if main returns, startup code will either hard fault, or simply re-run main, and absent information about your startup code (if any) either result is entirely expectable.
It's not at all clear that you've even loaded your code into the flash or RAM of your target, and not merely made the openocd tool aware of it. The openocd command reset run merely restarts the processor in running mode, if you have not already made it such that your processor will execute the desired code on reset, then that is not what is going to happen.
Your chip likely has various startup modes and flash banks, the current setup via programmable configuration bits or pin strapping may not be compatible with your goals.
code could have accidentally been built targeting a slightly different processor, for example building for one with more RAM than actually present would typically result in the initial stack pointer (traditionally the top of physical RAM) being at an invalid address
while in most cases clock selection falls to user code, eg, in main() or something it calls, it's possible that a routine trying to startup an external crystal oscillator and PLL could hard fault if that circuitry were not working
In terms of possible paths forward, the IDE-independent support code and examples package for the SAM chips is the ex-Atmel Advanced Software Framework (ASF).
But given that this question originally contained Arduino code, the asker may prefer to do a project or two using the vendor's offered IDE and not merely the stand alone support package. That IDE ultimately uses an ARM gcc as its toolchain, and it can export something akin to a Makefile, which is in horrid form but can with some manual effort be cleaned up into a model of how to maintain one's own project.
If openocd is going to be used as the flashing solution rather than the vendor's IDE, then effort will need to be invested in learning how to flash and control the chip with openocd. Generally this is possible, but some SAM targets in the past have needed minor fixes from the configuration files which shipped with certain versions of openocd.
If you feel that "platformio" has already dealt with some of the target specific issues for you, then you should probably focus effort on:
use arm-none-eabi-objdump to product a listing file of your program, and verify that it has the required vector table, startup code, etc
learn to use openocd to verify that your code is actually loaded into the processor
fix main to contain an infinite loop and not return
run your test with a sequence of commands more along the lines of a reset to halted mode and then single stepping, or place a breakpoint as early in startup code as possible
I have installed Atmel Studio 7 to a windows VM and copied the required files to my workplace on Linux. I tweaked the build commands a little bit and now it works. Here is the link to build the main.c file if anyone is interested. Running the build.sh results in a main.bin, which can be programmed to the samd51, without an IDE.
Edit: Assuming, of course, you have the arm toolchain and libnewlib-arm-none-eabi
