Good news, thanks for your feedback! So, ticket can be closed now.
---
** [tickets:#290] QSPI debugging is not working in some stm32h753 mcu**
**Status:** new
**Milestone:** 0.10.0
**Created:** Thu Jan 07, 2021 10:44 AM UTC by shaalik
**Last Updated:** Wed Jan 27, 2021 02:17 PM UTC
**Owner:** n
Just checked on a Nucleo-H743ZI2 (rev. *V*) with two W25Q256FV in dual-quad
mode: no issues with OpenOCD master. The errata sheet doesn't mention any
difference between Y and V regarding QSPI.
As mentioned above: Binary for Windows *with* stmqspi already included is
contained in STM32CubeIDE.
STM32CubeIDE includes OpenOCD with a rather recent stmqspi driver. You may give
it a try, although I still think your problem is hardware related. The drawback
is that ST squeezed all setups for various disco and eval boards into a single
stm32h7x.cfg, which makes adaption to your board slightly
On 2021-01-22 19:16, shaalik wrote:
> I took pre built binaries from http://openocd.org/getting-openocd/
>
> When i ran the cfg file I'm getting error as follows "Error: Flash
> driver 'stmqspi'not found
Naturally, as the prebuild windows binaries still don't include the
stmqspi driver. So you
The id will be checked just before the first comand touching the flash is
executed (setparms, mass_erase, ...), that's the auto_probe. Yes, it would be
nice if you could check whether commenting out the read_id helps.
But: Please don't use the old version. The updated patch had been merged
alr
I'm afraid there is no chance to investigate this any further. Maybe the WIP
bit sticks at '1' after reset, maybe the flash doesn't reply to RDJDID in QPI
mode (early revision, defective?), so you might try to use only SPI mode in
your cfg. Or replace the flash chip? Since it works on one board
That's odd ... The external connection of mcu to flash seems to be ok. I don't
see any reason anymore why it could work on one bourd and fail on the other.
The only reason I can imagine now is that the flash chip doesn't respond to
RDJDID (0x9F) properly.
But why I can't tell. Maybe your mcu
Naturally, the very same error would persists even with 0xEC. The point is,
however, does the memory mapped mode work correctly for the whole bank when you
comment out the setparms? I.e. does meromory contents read correctly on 4-4-4
mode then?
Connect to openocd with telnet on port and ins
Your CCR setting for memory mapped mode uses 4-line modes for instruction,
address and data, but instruction is 4FRQO (0x6C). DS however says:
Table 8.4: 4FRQO SPI, Quad data and
"8.8 FAST READ QUAD OUTPUT OPERATION (FRQO, 6Bh or 4FRQO 6Ch)
...
The FRQO/4FRQO instruction code is followed by thre
Your description isn't very helpful: Two identical boards, and your're
debugging the very same firmware on both? Or similar boards with different
firmware? And what's the error *precisely*?
Apart from that: First ideas would be
- Defective hardware (might not always be apparent at first glance,
The best idea is to compile it yourself as described in
http://openocd.org/doc-release/README On Linux that's rather simple and
painless.
---
** [tickets:#271] STM32L4RET fails to flash for image bigger than 256KB**
**Status:** new
**Milestone:** 0.9.0
**Created:** Sun Jun 21, 2020 03:17 PM U
There is to my knowledge no such device like STM32L4RET. The id 0x415 suggests
something like L47xRET?
There had been a major update of the stm32l4x driver recently, hence you
should test an up to date build of openocd first.
If that still shows the error, it would be useful if you could supply
On Nucleo-L053RZ no problem even with 4 MHz SWD clock via integrated ST-Link.
Although the L053 differs substantially from L011, the CPU core and debug logic
are certainly quite similar.
Custom board, original ST-Link? Stable power-supply, suitable bypass, no
glitches? SWD connection via jumper
The cause seems to be a silicon bug, cf. ES0290, "2.4.4 Memory-mapped read
operations may fail when timeout counter is enabled.". That was already
mentioned by Christopher Head.
The options are a) disable timout altogether (i. e. replace in the cfg file
mww 0xA0001000 0x0358
Oh, yes, overlooked the watchdogs at the very end of the features list ...
I didn't mean brand-new. Just do a mass-erase and verify that option bytes are
at factory settings (in particular hardware/software watchdog), power-cycle
board and stlink, and restart OpenOCD. This should be sufficient t
The size of working area *must* not have any influence except speed (as long as
the memory is present and operating properly), otherwise there is probably a
bug lurking around: The L073 hasn't got ECC for RAM nor watchdogs, which could
cause obvious trouble. Hence it might be useful to dig into
There is a patch available at http://openocd.zylin.com/#/c/4876/ to support
flash chips with capacity more than 16 MBytes. However, please note that
depending on the particular type it might additionally be necessary to switch
the flash chip to 4-byte address mode, either always after power-up o
That's not a bug but rather missing functionality, cf.
http://openocd.zylin.com/#/c/4853/
I'll submit a suitable patch as soon I'll get appropriate hardware for testing,
but this might take some time ... If you can't wait, you could do it yourself,
it should be fairly easy.
---
** [tickets:#2
Well, the check for allowed commands seems to be to restrictive. Either comment
out this check or add the required commands to this check. It's in
"COMMAND_HANDLER(stmqspi_handle_setparms)" in stmqspi.c.
Or, add your flash chip to the list in spi.c.
BTW: There is an update of the stmqspi drive
Ok, looks good, id is correct. Your cfg file still contains some things
specific to the example:
The RSTEN and RST instructions may not be appropriate to your chip, so I'd
suggest to remove that (or check your datasheet). But in the very same way you
may configure your flash, see below.
Since
It would be quite helpful to include your cfg file ... as the
"Warn : no flash bank found for address 0x9000"
strongly suggests that the qspi flash bank hasn't been set up (properly).
As long as 'flash probe 2' doesn't show the correct id of you flash chip(s),
there ist no hope the qspi driv
Not impossible, but subject to a lot of severe restrictions:
- instruction set must be similar to NOR flash (the instruction codes
may be different, but the basic operations must be similar), no serious
problem
- bad block management must be transparent to read command, i. e. the
flash must re
stmqspi is a driver/patch for openOCD to program and read the QSPI
flash, so it's to be build *into* openOCD executable only. For openOCD
you need in addition a small script, the patch comes with some examples,
e. g.
"stm32f769i-disco.cfg".
But for your board you have to write your own script,
Hello Praveen,
I'm afraid I can't help regarding a Windows build as I don't use/have
Windows at all ...
Regards,
Andreas
On 2018-10-01 22:44, Praveen wrote:
> Is it possible to get the openocd exe with the patch@4321 applied and
> built for windows ?
---
** [tickets:#208] Open OCD for extern
Do you want to use the external ***NAND*** flash for "execute-in-place",
i. e. the QSPI interface in memory-mapped mode? If yes, then I doubt
very much this is feasible at all: The quite page-oriented (in read
mode!) structure, bad block management and high error rate found in
***NAND*** flash
Do you want to use the external ***NAND*** flash for "execute-in-place",
i. e. the QSPI interface in memory-mapped mode? If yes, then I doubt
very much this is feasible at all: The quite page-oriented (in read
mode!) structure, bad block management and high error rate found in
***NAND*** flash
I've created an elf file with the same section addresses/sizes, filled with
garbage, test_image reports the same figures as for yor file. No problem
whatsoever, programming and verification works ok for me. Checked with ST-Link
V2J30M19 and V2J31M21.
Other than the chip rev. (yours is Z, mine is
Hm, just checked with current head on Nucleo-F767ZI via integrated ST-Link:
stm32f2x user_options 0xDFC, boot_add0 0x0080, boot_add1 0x0040,
so in dual-bank mode, after mass erase.
Programming the whole flash (2MBytes) with random data (flash write_bank 0
random.bin) and verify after read back (f
28 matches
Mail list logo
