SAM-BA Not Writing to SAMD21 Flash

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

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. 

 

Attachment(s): 

This topic has a solution.
Last Edited: Wed. Jun 24, 2020 - 05:27 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's not that simple to write in flash. You need to erase for example. Maybe look at this bootloader code

https://github.com/adafruit/uf2-samdx1/blob/master/src/flash_samd21.c

 

With SAM-BA similar is performed by an "applet" (i.e., it's not part of the bootloader code, rather fetched and executed by the bootloader).

/Lars

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Thank you for your help. The bootloader code you pointed me to helped me understand how to write to flash memory. It also lead me to find the section in the SAMD21 datasheet that describes the flash erase/read/write processes pretty clearly. In all my searching prior to my post I had not been directed to that section. It would have saved me alot of headache except for one aspect of the erase process.

 

The part of the erase process that still confuses me is why the address you want to erase needs to be divided by 2 when written to the ADDR register. I found that this is required by reviewing the code you linked to. Without that code I would not have known to do that. There is a note in the datasheet (seen below) that 16-bit addressing is used, but I do not see how that would equate to the address needing to be divided by 2. 

 

 

If any insight could be given about the issue above I'd appreciate it, but with the your previous help I have been able to get my bootloader all sorted out and the original issue is solved. Thank you for your help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hii, I am too working on a similar project on uploading a firmware over USB on SAMD21 using the android app. Can you guide me on how you made it? I'm having trouble finding a good way to do that. I searched quite about it on the internet but the works I saw are not related. I would appreciate any help you do.