---
** [tickets:#234] Problems with experimental driver for STM32 QUAD-/OCTOSPI
interface**
**Status:** new
**Milestone:** 0.9.0
**Created:** Mon Apr 29, 2019 07:01 AM UTC by David
**Last Updated:** Mon Apr 29, 2019 07:01 AM UTC
**Owner:** nobody
Copy of the problem I [reported via
gerrit](http://openocd.zylin.com/#/c/4321/). Maybe this bug tracker is a more
suitable platform to discuss the issue. Original report:
Hi,
I just tried out the latest version of this patch (i.e. directly checked out
original commit
a20cc9de2c63d7211a49cbe1231a06808ab89415) and compiled on Ubuntu 18.10.
On the STM32F746G-DISCO board (using board/stm32f746g-disco.cfg)
the flashing of the external QSPI flash works correctly, however during the
'verify' step hardware seems to crash:
~~~
** Programming Started **
auto erase enabled
Info : device id = 0x10016449
Info : flash size = 1024kbytes
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x20000044 msp: 0x20040000
Info : flash1 'micron n25q128' id = 0x18ba20 size = 16384kbytes
target halted due to breakpoint, current mode: Thread
xPSR: 0x21000000 pc: 0x200000d8 msp: 0x20040000
wrote 5373952 bytes from file firmware.elf in 94.322731s (55.639 KiB/s)
** Programming Finished **
** Verify Started **
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20040000
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20040000
Error: timed out while waiting for target halted
Error: timed out while waiting for target halted
Error: error executing cortex_m crc algorithm
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f7x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms
** Verify Failed **
shutdown command invoked
~~~
If I reboot the board after the failed 'verify' step everything is all right
and the QSPI flash shows the correct content
Andreas replied:
> Patch Set 5:
>
> Could you please supply:
>
> exact command line arguments
> value of all option bytes
> debug log (start openocd with additional '-d3')
>
> Does this problem occur every time or occasionally?
> Does a prior mass erase of F746 and SPI flash (instead of auto-erase) affect
> whether this occurs?
>
> BTW I'm wondering about the speed, just 55 kB/s. On a similar sized image I
> get about 85 kB/s with auto erase and 150 kB/s without erase. If you get a
> much lower rate when not using auto erase but prior mass erase, there must be
> something wrong with the configuration. The programming speed is more or less
> only governed by SWD clock, and that's set to 4 MHz in the cfg.
>
> It might be better to open a ticket and post the info there.
---
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.
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel