-
So here are some hexdump of various files: Apparently, the code coming from mbed online compiler is different from the one obtained by @DrAzzy on the espruino build as it places the second vector at $08xxxxxx while espruino places it at 0x20xxxxxx.
Compiled on Filename Hexdump
13 October 2014 ds18b20_test_NUCLEO_F401RE.bin 00 80 01 20 b1 01 20 08 b9 01 20 08 bb 01 20 08 bd 01 20 08 bf 01 20 08 c1 01 20 08 20 20 20 20
18 October 2015 espruino_1v81.79_nucleof401re.bin 00 80 01 20 d9 2a 03 20 55 24 03 20 51 24 03 20 4d 24 03 20 41 24 03 20 3d 24 03 20 20 20 20 20
18 October 2015 get_serial_number_NUCLEO_F401RE.bin 00 80 01 20 b1 01 20 08 b9 01 20 08 bb 01 20 08 bd 01 20 08 bf 01 20 08 c1 01 20 08 20 20 20 20
You are reading a single comment by @asez73 and its replies.
Click here to read the full conversation.
asez73
Hmm, interesting.
Could you use a hex editor and write the first 8 bytes of a bin file that works and one that doesn't? If they're hex files, just the second line would be enough.
This would be really frustrating. Flash memory is mapped to both 0x00000000 and 0x08000000 - so both addresses are valid. Espruino uses a reset vector at 0x00000000 because it sometimes produces smaller code, but it's possible that some idiot at ST has changed their bootloader so that you can ONLY upload code that runs from 0x08000000!