Hi, I am working on a project that uses the SAM-BA bootloader on a SAMD21G18A MCU. I was originally using v2.15 of the bootloader and utilizing the USB for writing new binary files to the board. I recently started on the task of editing the v2.18 SAM-BA source code to create a bootloader that allows me to write a new binary file over USB or the UART of the Bluetooth module that is connected to the SAMD21. I have created a companion android app that will handle writing the binary file over Bluetooth.
I have successfully edited the SAM-BA source code to use the UART pins of the Bluetooth module and have verified that the android app is able to communicate with the bootloader. Right now I am trying to use the 'S' command (see link below) of SAM-BA to write the file, but I am running into an issue when the bootloader tries to write the bytes of the binary file to Internal Flash Memory. To test out that the issue is caused by writing to Internal Flash, I tried using the 'O', 'H', and 'W' commands to write to 0x2000 (the start address for my application) then read the data back with the 'o', 'h', and 'w' commands.
Oddly this is the best description of the SAM-BA commands that I could find: https://sourceforge.net/p/lejos/wiki-nxt/SAM-BA%20Protocol/
I found that the O command causes the bootloader to stop executing while the 'H' and 'W' commands were processed, but the value at 0x2000 did not update. Below is the code used by the bootloader to write values to memory with all of the commands I mentioned. The "getbytes" function is the one used by the 'S' comand to store the bytes sent in the xmodem packets.
In all of the cases above, "ptr_data" is a uint8_t pointer with the value of 0x00002000. When the pointer is deferenced as type uint8_t, like is done in the 'O' command and the getbytes function, the bootloader stops executing. When the pointer is cast as a uint16_t or uint32_t pointer then dereferenced, the write is processed, but the value stored at 0x00002000 does not change.
I have verified that the BOOTPROT fuse is set to 0x7 and the lock bits are set to 0xFFFF. As far as I can tell, there should be no protection on the Internal Flash Memory, but that is exactly what it seems like. I have tested writing bytes to SRAM (0x20000000) and it works. If anyone is able to provide insight into this issue, I would greatly appreciate it. I am not very familiar with bootloaders or this type of memory access, so I may be missing some thing obvious, but I have tried searching for a solution and could not find one.