Menu
▾
▴
Re: [OpenOCD-user] Trouble programming flash memory on ATSAMD21 chip with STLink V2 interface
|
From: Tomas V. <to...@us...> - 2015-10-23 19:36:14
|
Hi Tony STLink V2J17 was the very version I experienced problems with PSoC4. However I don't think that even upgraded STLink is usable for SAMD. You succeeded with load_image command. It writes directly to memory and is usually used for loading to RAM. SAMD21 version A has a weird errata: *1 - Default value of MANW in NVM.CTRLB is 0. Errata reference: 13134* This can lead to spurious writes to the NVM if a data write is done through a pointer with a wrong address corresponding to NVM area. *Fix/Workaround:* Set MANW in the NVM.CTRLB to 1 at startup 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. I tested flash write_image intended for flash operation and got same error like you: Debug: 470 272275 target.c:2288 target_write_u16(): address: 0x41004000, value: 0x0000a502 Debug: 471 272275 hla_target.c:766 adapter_write_memory(): adapter_write_memory 0x41004000 2 1 Debug: 472 272276 stlink_usb.c:399 stlink_usb_error_check(): Verify error Debug: 473 272276 target.c:2293 target_write_u16(): failed: -4 Similar error is raised in erase_sector a probably in any other flash command. AFAIK the problem is in half word (16-bit) write to NVMCTRL->CTRLA register. STLink does not implement half word memory access and OpenOCD emulates is as two byte operations. Unfortunately CTRLA register comprises from key and command an have to be written atomically. If STLink writes two bytes, NVM controller sets PROGE bit in STATUS: "An invalid command and/or a bad keyword was/were written in the NVM Command register" I tested to use word (32-bit) write instead of half word and it solved the problem. However this is a dirty workaround for one (not too suitable) SWD adapter and I'm reluctant to propose it as change of SAMD driver. On the other hand we should not neglect that SAMD21 is in Arduino Zero (original with mEDBG and clones with bootloader only?) and this problem may become a FAQ. Anyway I recommend you to use other adapter than STLink for Atmel SAM MCUs. Tomas On 21.10.2015 19:24, Tony DiCola wrote: > Hi Tomas, thanks for the advice! I just tried STLink's firmware tool > and it looks like my STLink V2 was on firmware version V2J17S4 and a > newer version V2J24S4 was available. I upgraded to that latest > firmware V2J24S4 and wouldn't you know it everything works now! I can > see the load_image command works great and responds that all the data > was written: > >> load_image samd21_firmware.hex > 6328 bytes written at address 0x00000000 > downloaded 6328 bytes in 0.222035s (27.832 KiB/s) > > Thanks again for the advice, and FYI to anyone else using the STLink > with SAMD (and maybe other SAM chips), make sure to upgrade to the > latest firmware. Thanks! > > -Tony > > On Wed, Oct 21, 2015 at 12:18 AM, Tomas Vanek > <to...@us...> wrote: >> Hi, >> >> please first check if you have up to date ST-Link firmware. And use >> shortest cables >> as possible to avoid interference problems. >> Feel free to post to OpendOCD-devel as you already dig into depth of the >> problem. >> Please attach full -d3 log next time. >> >> I've never tested SAMD with STLink. I'm currently working with a SAMC21 >> custom >> board so I eventually try with STLink. >> >> Tomas >> >> On 21.10.2015 8:05, Tony DiCola wrote: >>> Hi all, I'm running into a lot of trouble programming the flash memory >>> of an Atmel SAMD21 chip (specifically the ATSAMD21G18A, a 256kb flash >>> memory Cortex M0) and am curious if anyone has pointers or experience >>> programming this chip with an STLink V2 programmer & OpenOCD. >>> >>> Here's a little bit about my setup: >>> - OpenOCD version: 0.9.0 (2015-06-30-17:02) >>> - Target: ATSAMD21G18A (same as in the Arduino Zero board), using the >>> stock at91samXX.cfg target config >>> - Interface: STLink V2, using the stock stlink-v2.cfg >>> - Protocol: SWD >>> >>> The problem is that I can't get any of the flash memory programming >>> functions to work. I can connect just fine to the chip, halt it, read >>> memory, do a full chip erase (with the 'at91samd chip-erase' command), >>> etc. However I've tried all the flash programming commands I can find >>> and each fail in a slightly different but related way. >>> >>> And just to answer an obvious question, yes I've checked that any >>> flash write protection and bootloader protection is disabled (using >>> the 'at91samd bootloader 0' command to disable bootloader >>> protection--the 'flash info 0' command also shows all 16 sections are >>> not protected too). >>> >>> - flash write_image throws an error "Failed to erase row containing >>> 00000000". Digging into the debug output (with -d 3) I see the >>> problem is this: >>> >>> Debug: 470 272275 target.c:2288 target_write_u16(): address: >>> 0x41004000, value: 0x0000a502 >>> Debug: 471 272275 hla_target.c:766 adapter_write_memory(): >>> adapter_write_memory 0x41004000 2 1 >>> Debug: 472 272276 stlink_usb.c:399 stlink_usb_error_check(): Verify error >>> Debug: 473 272276 target.c:2293 target_write_u16(): failed: -4 >>> >>> Crawling through the code a bit it looks like after issuing the erase >>> row command to the NVMEM controller on the chip the STLink is throwing >>> back a STLINK_JTAG_WRITE_VERIF_ERROR error. I'm kind of at a loss at >>> this point as to what the problem could be--anyone hit this issue and >>> have suggestions? >>> >>> - load_image executes but silently fails. A blank line is output, but >>> examining the debug output I see it's hitting a timeout error: >>> >>> Debug: 513 854015 target.c:1970 target_write_buffer(): writing buffer >>> of 6328 byte at 0x00000000 >>> Debug: 514 854015 hla_target.c:766 adapter_write_memory(): >>> adapter_write_memory 0x00000000 4 1582 >>> Debug: 515 854027 stlink_usb.c:393 stlink_usb_error_check(): wait >>> status SWD_DP_WAIT (0x10) >>> Debug: 516 854042 stlink_usb.c:393 stlink_usb_error_check(): wait >>> status SWD_DP_WAIT (0x10) >>> Debug: 517 854080 stlink_usb.c:393 stlink_usb_error_check(): wait >>> status SWD_DP_WAIT (0x10) >>> Debug: 518 854098 stlink_usb.c:393 stlink_usb_error_check(): wait >>> status SWD_DP_WAIT (0x10) >>> Debug: 519 854142 stlink_usb.c:393 stlink_usb_error_check(): wait >>> status SWD_DP_WAIT (0x10) >>> Debug: 520 854172 stlink_usb.c:393 stlink_usb_error_check(): wait >>> status SWD_DP_WAIT (0x10) >>> Debug: 521 854239 stlink_usb.c:393 stlink_usb_error_check(): wait >>> status SWD_DP_WAIT (0x10) >>> Debug: 522 854318 stlink_usb.c:393 stlink_usb_error_check(): wait >>> status SWD_DP_WAIT (0x10) >>> Debug: 523 854481 stlink_usb.c:393 stlink_usb_error_check(): wait >>> status SWD_DP_WAIT (0x10) >>> Debug: 524 854481 command.c:628 run_command(): Command failed with error code -5 >>> >>> Looking at the code it looks like there's a minor bug in OpenOCD error >>> logging here--the stlink_usb.c function stlink_usb_write_mem can fail >>> without logging an error if it exceeds the number of retries from a >>> ERROR_WAIT response (this code: >>> https://github.com/ntfreak/openocd/blob/master/src/jtag/drivers/stlink_usb.c#L1509-L1514). >>> This goes against the assumption in the comments here that commands >>> will print out an error if they fail: >>> https://github.com/ntfreak/openocd/blob/master/src/helper/command.c#L624-L629 >>> This is just a minor issue though and not related to my problem--I >>> just wanted to raise it in case anyone else has noticed commands >>> silently failing. >>> >>> Back to the load_image problem it appears I'm hitting the timeout >>> while writing to the chip. Has anyone run into this issue and have >>> any workarounds? From looking at the code it looks like it's >>> hardcoded to a max of 8 retries over the course of about 0.25 seconds. >>> >>> - Finally the program command fails with the same "Failed to erase row >>> containing 00000000" error as flash write_image above. I assume >>> internally the program script is just calling flash write_image so >>> it's the same JTAG verify error. >>> >>> Unfortunately I'm really stumped why I can't seem to get OpenOCD to >>> program this chip using a STLink V2 programmer. I can program the >>> same chip just fine with a Segger J-Link and their JLink tools so it >>> doesn't appear to be a hardware or other physical issue. I've also >>> used this same STLink V2 to program a few other chips from Nordic, >>> STM, etc. without issue so it should be fine. And as mentioned >>> earlier OpenOCD can connect and control the chip just fine, it's only >>> the flash memory writes that fail. >>> >>> Anyone have any pointers or idea what could be going wrong trying to >>> flash the ATSAMD21 with the STLink? I'd really like to be able to use >>> the STLink V2 programmer here but I'm kind of hitting a brick wall >>> with the JTAG verify error & hard coded timeout. >>> >>> Also let me know if the user list isn't appropriate for this issue and >>> if I should move it to the developer list instead. Thanks! >>> >>> -Tony >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> OpenOCD-user mailing list >>> Ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/openocd-user >>> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> OpenOCD-user mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openocd-user |
