I have been using a small SAMD21E16B (64k/8k) and thought things were fine.
Then I switched to a bigger SAMD21J18A (256k/32k) part and bad things
happened.
Version
-------
Open On-Chip Debugger 0.10.0-dev-00419-gbcaf775-dirty (2016-12-21-14:48). I
am a bit behind master but the file in question, at91samd.c, is the same.
Background
----------
I have an 8kB bootloader at address zero and an application that begins at
0x2000. On the 'E16B part I could SWD program the bootloader at 0 and then
SWD program the application at 0x2000 using gdb and openocd. This does not
work with the bigger flash size on the 'J18A though. I would SWD program
the bootloader and my application would get erased and vice versa.
Investigation
-------------
I ran openocd under control of my host gdb and started snooping around. I
found that flash/nor/at91samd.c had hard coded the number of sectors to 16.
This is not actually the case. There are exactly 16 *LOCK* regions but the
number of erase rows (sectors?) varies depending upon the size of the flash
array.
When the chip->sector_size is calculated it just takes the size of the
flash array and divides it by SAMD_NUM_SECTORS (16). For the 'E16B I got
lucky because 64k/16 = 4k and my bootloader fit under 8k and my application
started at 0x2000 (8k). Thus, gdb was able to erase and program the
bootloader and the application without erasing the other.
For the 'J18A chip->sector_size is 256k/16 = 16k. So now when gdb programs
the bootloader he erases beyond the 8k and blows away part of my
application. Likewise, to program the application gdb will now erase the
bootloader as well. Not good.
Design Issue
------------
There appears to be a design decision to link the protection region size to
the erase granularity (size). This provides correctness when it comes to
locking flash regions but is not particularly friendly to programming
smaller-than-lock-region sized programs when there are more than one copy
of these programs to be flashed at different times as is the case for me
and my bootloader + application.
Work-Around
-----------
In my sandbox I have removed SAMD_NUM_SECTORS and added
SAMD_PAGES_PER_SECTOR and SAMD_LOCK_REGION_SIZE. Next I set
chip->sector_size = chip->page_size * SAMD_PAGES_PER_SECTOR (4) and
bank->num_sectors = bank->size / chip->sector_size. Then I realized that
samd_protect_check() would be wrong because my bank->num_sectors would be
large, far larger than the 16 that were assumed so just set all the
is_protected flags to zero and ignored the 16-bit LOCK register value. This
is okay for me at this point since I don't lock any regions. Finally I had
to update samd_erase() to loop over the now-correct number of actual
sectors (rows) instead of a fixed 16 sectors with a sub-iteration of rows
per sector.
Now gdb and openocd can correctly erase and program all SAMD parts with the
correct erase sector size (4 x page_size = 256 bytes) however I cannot lock
flash regions. I'm not sure what it really means to lock a region at this
point either. If a lock region on the 'J18A is 16kB and I want to lock a
single 256 sector (row) then I simply cannot do it; the chip will lock the
entire encompassing 16k region. What to do? Expose the lock region size to
gdb? Does gdb know about locking something other than a sector? Should
locking regions be moved to an atxxxx command like chip_erase?
Not sure what to do. Any suggestions?
--
- Mark
(mrfirmw...@gmail.com)
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
