Tomas,
Ignoring the block protect bug, your patch worked great for me. Thank you.
However, there is some change after commit
bcaf775fc10d88d2c63c06bafada141895318b34 that causes me to take an assert.
This happens on the current master with or without your patch. Here's the
backtrace:
#1 0x00007ffff711c02a in __GI_abort () at abort.c:89
#2 0x00007ffff7112bd7 in __assert_fail_base (fmt=<optimized out>,
assertion=assertion@entry=0x55bd95 "jtag_trst == 0",
file=file@entry=0x55bd78
"core.c", line=line@entry=343,
function=function@entry=0x55c498 <__PRETTY_FUNCTION__.9285>
"jtag_checks") at assert.c:92
#3 0x00007ffff7112c82 in __GI___assert_fail
(assertion=assertion@entry=0x55bd95
"jtag_trst == 0",
file=file@entry=0x55bd78 "core.c", line=line@entry=343,
function=function@entry=0x55c498 <__PRETTY_FUNCTION__.9285>
"jtag_checks") at assert.c:101
#4 0x0000000000404c7a in jtag_checks () at core.c:343
#5 0x0000000000407563 in jtag_checks () at core.c:353
#6 jtag_prelude (state=<optimized out>) at core.c:348
#7 0x0000000000407d33 in jtag_add_ir_scan_noverify (active=0x902020,
in_fields=0x7fffffffd910, state=TAP_IDLE)
at core.c:358
I also found that scripts/target/at91samdxx.cfg changed and caused my
target->state to be TARGET_RESET not TARGET_HALT. This was commit
25d7ba19c9e70cf5b912f660cf6aaa93d9ca120f and it 'srst_pulls_trst' to the
reset_config. This does not work with my Atmel SamICE configured for SWD on
my custome target board.
So if you bisect between master's HEAD and
bcaf775fc10d88d2c63c06bafada141895318b34 with your patch you may be able to
recreate the problems I'm seeing.
On Thu, Dec 22, 2016 at 1:30 AM, Tomas Vanek <tom_...@users.sourceforge.net>
wrote:
> Please try
> http://openocd.zylin.com/3546
> and give a review.
>
> Tomas
>
>
> On 21.12.2016 23:56, Mark Odell wrote:
>
> 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>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
> listOpenOCD-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/openocd-devel
>
>
>
------------------------------------------------------------------------------
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
