Microchip SAMV71: OpenOCD Flash Erasing Oddity (timeout if erasing whole flash)

[Microawesome]

Hello!

This is my first post on this forum so apologies if I go against convention in any way. I am happy to be redirected to a more proper location and repost if necessary.

I have been attempting to use OpenOCD in conjunction with the Cortex.Debug plugin/extension for VSCode to flash firmware to the ATSAMV71Q21B on the SAM V71 Xplained Ultra Evaluation Kit. I have managed this before on several occasions with a standard launch.json launch configuration that I made as seen in the attachment below ("Working Launch Configuration.png").

However, the problem arose when my colleague sent me a project of his. We are using the same versions of everything from the compiler version, to the cortex.debug plugin version, to the version of OpenOCD (0.12.0). The launch configuration can be seen in the attachment below ("Broken Launch Configuration.png"). When using the broken launch configuration, which my colleague had success with, I am faced with the errors seen in the attachments below ("Error Erasing Flash (OpenOCD Window).png" and "Error Erasing Flash (GDB Window)").

Each launch configuration that I try always seems to fail if it is required to erase the whole flash in one operation (which this particular firmware does because it's a bootloader packaged with other programs which takes up the entire flash). Attached you can see that when I erase sectors 0 through 126 and THEN erase sector 127, it passes no problem ("Success When Erasing Sectors 0 to 126 and then 127.png")! However, the second I attempt to erase all sectors at once, it triggers the use of a different function which times out since the FRDY bit of the flash controller never appears ready (always 0x00), or at least that's what my debugging to this point tells me. You can see that even when I explicitly use the "erase_sector" directive in OpenOCD, I still see the operation timeout ("Failed to Erase Sectors 0 to 127.png"). The "program" directive also attempts to erase the entire flash before flashing the firmware and thus times out as well.

If anyone has any ideas on why this could be occurring I would be extremely grateful. Both myself and my colleague have lost hope on this issue. Although we have the workaround of erasing 0 through 126 and then 127, we would very much like to know the root cause of the issue rather than working around it.

Thanks in advance everyone!

[ataradov]

What are the timeouts?

I don't know what OpenOCD calls a "sector" for this device. In the datasheet nomenclature there are not 128 sectors in the device, so I suppose it is some number of pages. What is the actual size being erased? Erasing the device by individual sectors may take up to 30 seconds, so increasing the timeouts would be the first thing to try.

[Microawesome]

What are the timeouts?

I don't know what OpenOCD calls a "sector" for this device. In the datasheet nomenclature there are not 128 sectors in the device, so I suppose it is some number of pages. What is the actual size being erased? Erasing the device by individual sectors may take up to 30 seconds, so increasing the timeouts would be the first thing to try.

Hello, thank you for replying. The timeouts usually last anywhere from 10-12 seconds. It is not a consistent or exact number of seconds by the looks of things.

As for the sectors, I did some digging and , as you know, according to the SAMV71Q21 datasheet "The memory is organized in sectors. Each sector has a size of 128 Kbytes.". This is followed by a diagram (attached) demonstrating the layout of the first sector and all subsequent sectors, of which there are 16 given the total flash size of 2048Kb. However, what OpenOCD appears to be referencing is the "lock regions". "A lock region is composed of several consecutive pages, and each lock region has its associated lock bit.". So it appears, given there are 128 lock bits for lock regions of size 16Kbytes each, OpenOCD is triggering the use of the Erase Pages Command (EPA) via the EEFC peripheral's EEFC Flash Command Register to delete 32 pages (512bytes each * 32 = 16Kbytes. 2048/16 = 128 "sectors") at a time, meaning 128 erases in total to erase the whole flash.

What's interesting is when I use the '-d3' debugging option on an OpenOCD process, I notice that upon attempting to erase all 128 "sectors" via the "flash erase_sector 0 0 127" command, it uses the EEFC peripheral's EA (Erase All) command instead (see"Flash Erase All Command Followed by Endless FRDY status bit checks.png"), and then it probes the FRDY status bit until the timeout is triggered. I'm not entirely sure what I can do with this information but it does hint at either a misuse of the EA EEFC command, or a regular timeout due to its likely longer runtime.

As for your recommendation of increasing the timeout, I have thus far been unable to do so for this particular command. I can only seem to increase the GDB remote timeout via the openocd launch commands, which is an entirely separate timeout mechanic from the EEFC commands that it is performing. Of course, that's just as far as I could find, if you know how to extend the timeout for the EA EEFC command, I would be extremely grateful to know how.

Also, the actual size being erased is the entirety of the flash (2048Kbytes) as this is a bootloader packaged with several copies of firmware and additional padding.

Thanks for your help thus far.

[aeg]

Build openocd from sources, increase the ms_end calculation at the top of samv_efc_perform_command, see if that helps

[Microawesome]

Build openocd from sources, increase the ms_end calculation at the top of samv_efc_perform_command, see if that helps

Yeah I considered doing that, was just hoping there was another option considering this worked flawlessly for my colleague without building from source using OpenOCD version 0.12.0 .

[aeg]

What happens when your colleague runs with -d3?

[Microawesome]

What happens when your colleague runs with -d3?

I have asked him to perform the "flash erase_sector 0 0 127" action with -d3 flag on. He works in another country so I will update this post once he has completed that. I'm open to any more ideas in the meantime.