I'm working with an Arduino MKR WAN 1310 board and I'm flashing the firmware using a Segger J-Link. I generated a .bin file from my sketch without including the bootloader and programmed it directly using the J-Link.
The binary seems to flash correctly — the programming process completes without errors. However, when I reset the board, the CHRG LED starts blinking continuously and the board doesn't seem to execute the uploaded code. No serial output, no response from the MCU — it's like it's stuck.
If I flash the same code using the Arduino IDE (which includes the bootloader), everything works fine. So it seems like flashing without the bootloader causes this issue.
Does anyone know what might be causing this? Is there something additional I need to configure or include in the binary to make it boot correctly when bypassing the bootloader?
I will take a SWAG since your code is invisible and say:The AVR processor starts execution at address 0x0000 after a reset. This address typically contains a Relative Jump instruction to the reset handling routine within the bottom 4K of memory. Your code must take care of this as the boot loader is no longer there.
Shouldn't the linker script take care of that part? at the end I still compiling the main.cpp from arduino.
Checking the linker script of binaries with bootloaders it looks like the only difference is acknowledging the offset from the bootloader (and not overwriting it).
Should I just define and implement 'Reset_Handler' in code?
From what I understand the vector table must be located at address 0 at reset, from that I gather that The ARM will grab its initial stack pointer from 0x0, and the initial start address from 0x4. These are pure addresses, not jump instructions. After that it is up to the user software to place that table wherever it wants. Am I correct? I have never programed the part so I have only read small bits and pieces about it. I assume the stack pointer if fetched first so if there is a rouge interrupt it can recover although the interrupts should be disabled at reset.
Unfortunately I'm not knowledgeable in this subject matter. I did a quick search for related information in the issue tracker of the "Arduino SAMD Boards (32-bits ARM Cortex-M0+)" platform's GitHub repository (because I thought I remembered a report about a problem like this there), and I saw this comment from one of Arduino's developers that might be relevant:
