I've done some more testing wrt this issue and noticed that the failure is
reproduced without even using the second bank. Instead, just programming my
`fw.elf` multiple times causes exactly every-other attempt to program `fw.elf`
to fail. (running `openocd -f board/st_nucleo_f7.cfg -f d.cfg -c exit` each
time)
I've added some debug output to various code around stm32x_block_write to try
and figure out what in particular is failing (see attached output & patches).
I've added various `mov r5, #0xbb` (etc) instructions to try to track the
progression of the algorithm, initially setting r5 to 0xaa. In the failure
case, I've never seen anything by `0xaa`.
I've observed that the `r0` value returned by the algorithm (which should be
the flash status register) does not appear to actually be the flash status
register. It has bits set that are marked as "reserved" in the stm32f7/6xxx
manual and it's value appears to change as I change/add to the algorithm asm.
The value looks very much like a pointer to ram, possibly to the end of the
code composing the algorithm.
Attachments:
-
[success.txt](https://sourceforge.net/p/openocd/tickets/_discuss/thread/d27603e0/6340/attachment/success.txt)
(3.1 kB; text/plain)
-
[fail.txt](https://sourceforge.net/p/openocd/tickets/_discuss/thread/d27603e0/6340/attachment/fail.txt)
(3.4 kB; text/plain)
-
[d.cfg](https://sourceforge.net/p/openocd/tickets/_discuss/thread/d27603e0/6340/attachment/d.cfg)
(126 Bytes; application/octet-stream)
---
** [tickets:#203] programming st_nucleo_f7 (stm32f767) bank 2 consistently
fails**
**Status:** new
**Milestone:** 0.9.0
**Created:** Mon Aug 20, 2018 09:55 PM UTC by Cody Schafer
**Last Updated:** Thu Aug 23, 2018 08:11 PM UTC
**Owner:** nobody
In the `stm32f767zi` (on the nucleo-f767zi board), there is 2MiB of flash. When
it is configured into dual bank mode (`stm32f2x options_write 0 0xDFC 0x0080
0x0040`, presuming all other options are left at their defaults), using the
`program` command to program the second bank (`bank1_start=0x0810_0000`,
`bank2_start=0x0800_0000`) with the command `flash write_image fw.elf erase
0x100000`, the execution consistently fails with the following output:
`openocd -f board/st_nucleo_f7.cfg`
```
> flash write_image fw.elf 0x100000
Flash write discontinued at 0x081020c4, next section at 0x08120000
timed out while waiting for target halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x00000003 pc: 00000000 msp: 0xffffffe0
error waiting for target flash write algorithm
error writing to flash at address 0x08000000 at offset 0x00100000
```
This is using the embedded `ST-LINK` included on the nucleo. The st-link
firmware version is `V2J31M21`.
`fw.elf` has sections starting in bank1 of flash, which is why the offset is
only the difference between bank1 and bank2.
The banks refered to here are banks in the stm32f7x sense, and are _not_
openocd flash banks.
---
Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/openocd/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
