Re: [OpenOCD-user] Trouble programming flash memory on ATSAMD21 chip with STLink V2 interface

[Tony D. <to...@to...>]

Oh interesting, thanks for the tips Tomas.  Yeah I actually spoke a
little too soon, the load_image commands works for me but the flash
write_image command still fails with the same error.  I need to read
your reply a little more and check out the registers you mention.

I did however find a bug with the samd core and its use of the NVMEM
controller cache.  This section of the samd NVMEM write is trying to
flip bit 18 on a 16 bit value to disable the NVMEM controller cache
functionality: https://github.com/ntfreak/openocd/blob/d28ab08cfafb3ad7ff8dc539644883217e89f8c4/src/flash/nor/at91samd.c#L420-L424
 Unfortunately this doesn't have the intended effect (if you enable
debug output you can see it writes a 0 value to the ctrl B reg, but
reading the datasheet (page 367 here
http://www.atmel.com/images/atmel-42181-sam-d21_datasheet.pdf) and the
cache is actually enabled.

The problem I ran into is with the cache enabled a load_image command
seems to miss writing the last page of the cache to flash memory.  The
cache is 64 bytes large and I noticed the last 56 bytes of my program
memory was't being written to the flash memory.  The load_image
command succeeds, but running verify_image fails and notices the
missing data.  Kind a nasty bug to catch unfortunately since for small
writes it's probably never noticed.

Haven't had a chance to send a formal bug report about it yet, but I
want to try patching that function to treat the ctrl B register as a
32 bit value instead of a 16 bit value like it does today.  From the
DS the register is 32-bits large, at least for the samd21 (but I
assume all the other samd's?), so I think the whole function needs to
be adjusted slightly to account for this.

On Fri, Oct 23, 2015 at 1:18 PM, Paul Fertser <fer...@gm...> wrote:
> On Fri, Oct 23, 2015 at 10:10:40PM +0200, Tomas Vanek wrote:
>> But if the driver tests for a hla adapter, does it mean emulated halfword
>> access?
>
> I think TI's ICDI can do honest 16-bit access, so no, that wouldn't be
> accurate.
>
> I wonder stlink driver should print a warning every time a 16-bit
> write is attempted. IMHO that would help troubleshooting. I'd also
> probably changed the emulation to do 32bit read, mask, 32bit write
> instead of what it does currently, chances are it will work for more
> usecases and will likely break nothing.
>
> --
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fer...@gm...