shumatech / BOSSA

BOSSA is a flash programming utility for Atmel's SAM family of flash-based ARM microcontrollers. The motivation behind BOSSA is to create a simple, easy-to-use, open source utility to replace Atmel's SAM-BA software. BOSSA is an acronym for Basic Open Source SAM-BA Application to reflect that goal.
http://www.shumatech.com/web/products/bossa
BSD 3-Clause "New" or "Revised" License
361 stars 251 forks source link

SAM4S16- consistently fails to verify #109

Open dngbionics opened 4 years ago

dngbionics commented 4 years ago

Just built on Ubuntu 18.04 using the latest master (commit 820207).

All written pages fail to verify successfully.

Also note that the 'info' command seems to take unnecessarily long to process (about 5 seconds).

What can I do to help diagnose this issue?

bossa> connect /dev/ttyUSB2 Connected to device on /dev/ttyUSB2 bossa> info Locked : none Security : false Boot Flash : false bossa> erase Erase flash Flash is erased bossa> write ../test.bin Write 75032 bytes to flash (147 pages) [==============================] 100% (147/147 pages) Write successful bossa> verify ../test.bin Verify 75032 bytes of flash [==============================] 100% (147/147 pages) Verify failed Page errors: 147 Byte errors: 74640

dngbionics commented 4 years ago

Just tested with Release 1.9.1 and got exactly the same result. :`(

dngbionics commented 4 years ago

Reading back the flash contents shows the flash was still completely erased: bossa> read ../out.hex count:0 offset:0 Read 1048576 bytes from flash [==============================] 100% (2048/2048 pages) Read successful

$ hexdump ./out.bin 0000000 ffff ffff ffff ffff ffff ffff ffff ffff * 0100000

dngbionics commented 4 years ago

Hmmm...after more attempts my Writes are now failing consistently at 22% (no hardware or software changes made):

bossa> write ../test.bin Write 75032 bytes to flash (147 pages) [====== ] 22% (33/147 pages) Flash command failed.

Reads however are still working, and still show the flash is full of FFs even after the writes.

Gadgeteering commented 4 years ago

I think this is the same problem that I have had ( #108 ) the S16 has 8k of ram and Bossa Starr writing to the middle of the ram and overflows into the stack. The boot loader then crashes. The write buffer needs to be reduced see pull requests #110

haata commented 4 years ago

As a side note, I believe I have one dead ATSAM4S4B chip (was powered at around 4.2V for a while due to a pcb screwup). SAM-BA can attempt a write, but verifies tend to fail (other boards, which were always powered correctly, with some rework, work just fine).

adityathakekar commented 1 year ago

I have same issue with SAMD21E18A, is this closed in another thread?