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

[Tomas V. <to...@us...>]

Tony,

sure, this is a bug. Please don't waste time by a bug report. Read 
HACKING file
in OpenOCD root and push a patch for review.

CACHEDIS bit of NVMCTRL->CTRLB disables caching during read.
This is not related to your problem: last page was not written to flash
just because you used load_image instead of "flash write_image"
(and therefore flash command "write page" was not issued after incomplete
sector write).
That is exactly what I meant
> So it means that you can write image to a clean device *with possible 
> problem**
> **with unpadded last sector* - without any use of SAMD flash driver.

Tomas
P.S. If you cannot wait, forget load_image and try this

--- a/src/flash/nor/at91samd.c
+++ b/src/flash/nor/at91samd.c
@@ -452,7 +452,7 @@ static int samd_issue_nvmctrl_command(struct target 
*target,
                 return res;

         /* Issue the NVM command */
-       int res_cmd = target_write_u16(target,
+       int res_cmd = target_write_u32(target,
                         SAMD_NVMCTRL + SAMD_NVMCTRL_CTRLA, 
SAMD_NVM_CMD(cmd));

         /* Try to restore configuration, regardless of NVM command write


On 23.10.2015 22:30, Tony DiCola wrote:
> 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...