Try this:File > Preferences > Show verbose output during: > upload (check) > OKSketch > Upload (doesn't matter if it fails)After the upload completes examine the output in the black console window at the bottom of the Arduino IDE window until you find the command used to upload to the Arduino. This will give you the location of the .bin file that is uploaded.Upload that .bin file.This cuts out the Export Compiled Binary process so you know the .bin file you're working with is good. The Export Compiled Binary process should just be a copy + rename and a diff of the two files on my computer shows they are identical.Note that you will also find a .hex file in the temporary build folder along with the .bin file so that might also be worth a try.
At least now you know your original hypothesis ("that the export binary function of the Arduino IDE is not properly working.") is wrong.When the .bin file is uploaded via the Arduino IDE, using the command you see in the console, it works fine. So the problem lies somewhere in the difference between that command and the way you're attempting to flash the .bin file.
the board needs to have a bootloader in order to execute the sketch binary
That's expected behavior. Arduino Zero sketches are built to run at a non-zero start address in flash, because the bootloader starts at zero. At reset, the chip extracts some data about where to start from location zero in flash, so there MUST be something there.This is different from the AVRs, which:have a separate bootloader section at the end of memory, and a fuse that tells them to start there, so normal sketches still start at zero.actually start execution at either zero or the start of the bootloader section, rather than extracting startup info. So if you start at the beginning of the bootloader section when no bootloader is loaded, you go along executing useless but harmless instructions until the PC wraps around and reaches 0 (where your sketch would start executing.)
I dunno. Are you running "Blink" or something more complicated?ARMs will trap invalid memory accesses that an AVR would ignore, and probably just hang up as a result (not having an operating system to give you a "segmentation violation" error.)
ADC_LINEARITY_0 = 0x08ADC_LINEARITY_1 = 0x04ADC_BIASCAL = 0x03OSC32K_CAL = 0x37USB_TRANSN = 0x05USB_TRANSP = 0x1DUSB_TRIM = 0x03DFLL48M_COARSE_CAL = 0x20DFLL48M_FINE_CAL = 0x200ROOM_TEMP_VAL_INT = 0x1EROOM_TEMP_VAL_DEC = 0x00HOT_TEMP_VAL_INT = 0x55HOT_TEMP_VAL_DEC = 0x00ROOM_INT1V_VAL = 0x00HOT_INT1V_VAL = 0xFEROOM_ADC_VAL = 0xB81HOT_ADC_VAL = 0xD7ENVMCTRL_BOOTPROT = 0x07NVMCTRL_EEPROM_SIZE = 0x07BOD33USERLEVEL = 0x07BOD33_EN = [X]BOD33_ACTION = 0x01WDT_ENABLE = [ ]WDT_ALWAYSON = [ ]WDT_PER = 0x0BWDT_WINDOW_0 = [X]WDT_WINDOW_1 = 0x05WDT_EWOFFSET = 0x0BWDT_WEN = [ ]BOD33_HYST = [ ]NVMCTRL_REGION_LOCKS = 0xFFFFOTP4_WORD_0 = 0x40004007 (valid)OTP4_WORD_1 = 0x81F4ADDC (valid)OTP4_WORD_2 = 0xFFFFFE00 (valid)TEMP_LOG_WORD_0 = 0x5501E (valid)TEMP_LOG_WORD_1 = 0xD7EB81FE (valid)USER_WORD_0 = 0xD8E0C7FF (valid)USER_WORD_1 = 0xFFFFFC5D (valid)