Have not you selected jtag instead of swd transport?
SAMD obviously has no JTAG interface, however OpenOCD should not assert
anyway.
On 22.12.2016 17:41, Mark Odell wrote:
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 <mailto: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 <mailto: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
<mailto:OpenOCD-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/openocd-devel
<https://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
