There are provisions (e.g. in SFDP data) for up to 4 differerent (erase) sector
sizes. And most (all?) higher capacity devices have differerent sector sizes to
choose from. There are even devices where the large erase sector size can be
switched by some non-volatile register. Infineon came up w
Most SPI flash do support various "sector" sizes, 4kB is sometimes called
subsector. OpenOCD uses for bigger flash always the largest available size:
Erasing a substancial part by subsector erase is usually *much* slower than by
the larger sectors. E.g. for MT25QL512ABB: subsector 4kByte typ. 5
jtagspi cmd 0 1 0x05 ;# read status register
jtagspi cmd 0 0 0x06 ;# write enable
jtagspi cmd 0 1 0x05 ;# read status register again to check WEL
jtagspi cmd 0 0 0x01 0x40 ;# set QE bit (assuming BP to remain cleared)
Note that QE is a non-volatile bit, so it has to be set only once. From the
da
See 12.5.1 "Flash Driver: jtagspi
Command: jtagspi cmd bank_id resp_num cmd_byte ..."
Present in all not too old builds, see
https://review.openocd.org/c/openocd/+/4876
---
**[tickets:#422] Modify the FPGA flash status register**
**Status:** new
**Milestone:** 0.11.0
**Created:** Sun Feb 04
So, why do you think this is related to OpenOCD? If you fiddle around with
settings in a more or less arbitrary way, it's not that surprising that
something stops working.
Maybe you should simply revert these settings to their original values?!
---
**[tickets:#416] RP2040 QSPI Flash reset (no
jtagspi and stmqspi drivers do have a command to specify the properties of a
flash device at run time. That's not exactly what you described, but reasonable
close to it.
So, it's more or less a copy-and-paste of the "jtgaspi set" or "stmqspi set"
(see docs) command implementation to another fla
I'm afraid that - apart from your rather impolite wording - you're not getting
the point:
1) Your idea of a generic write method is technically infeasible. E.g. address
length or sector length (ATXP128 require 4-byte addresses, S25HL256 ... don't
have 4kB sectors) or non-volatile configuration
As long as continuous 'read' starting in bottom 16MByte via single line is
concerned, this might work in most cases. But:
- SPI flash might be configured (non-volatile!) to quad line mode.
- 'read' with start address above 16MByte requires banking register or 4-byte
addresses.
For 'program' ther
Well, as the initial version (simple SPI) was largely copy-and-paste from my
stmqspi driver, two weekends as far as I remember (the most cumbersome parts
were I2C and UNI/O interface). BUT: All required infrastructure in OpenOCD for
Cortex-M was already there. Can't say anything about Cortex-A
You could try to port https://review.openocd.org/c/openocd/+/4760 to Cortex-A.
Problem is to be able to use e.g. target_run_flash_async_algorithm and friends
(in src/target.c). There's already a helper script gpio_conf_zynq.pl included
but currently I've no spare time to address that.
---
**[
No real a idea, just some thoughts:
1) ST-Link firmware is rather old
2) First failing access at 0x5c001004 is in DBGMCU module, this does't look to
be QSPI related except:
3) Try debug session with "gdb_flash_program disable" right after power-on
reset of target.
4) Increase FSIZE by one upon in
"New version" means additional modes: dual-SPI, dual-DPI, dual-QPI, octal,
microwire (the 93 stuff). That's already implemented, but I still have to
run extensive tests to make sure there won't be a regression.
I'm afraid this will hardly ever make it into a OpenOCD release, as it's way to
Still not completely clear to me: Do you refer to SPI *mode* (i. e. CLK, MISO,
MOSI, NCS) or to SPI *interface*? As the QSPI and OctoSPI interfaces do support
SPI transfer mode, too.
---
** [tickets:#326] Support for external flash SPI driver for STM32L5**
**Status:** new
**Milestone:** 0.11.
What do you mean by "SPI" in this context? For the OctoSPI interface there's
stmqspi, which handles QSPI and OctoSPI interfaces.
For plain SPI, there's indeed no specific driver, but you could use
https://review.openocd.org/c/openocd/+/4760
(the latter one seems to be a bit outdated, but a new ver
What does 'skip' mean? Length ok? First two bytes garbage and rest ok including
the very last byte? Or does the dump start at third byte and has two 'extra'
byte at the very end?
The latter one would most likely due to mismatch of dummy cycles. MX25L51245G
allows configuration of dummy cycles, t
On 2021-06-20 14:12, Oleksandr Redchuk wrote:
нд, 20 черв. 2021 о 00:42 Andreas Bolsch пише:
On 2021-06-19 22:58, Oleksandr Redchuk wrote:
> FT2232D-based adapter
> The same behavior as Ali Tekin reported:
> "Error: error writing to flash at address 0x0800 at offset
>
On 2021-06-19 22:58, Oleksandr Redchuk wrote:
FT2232D-based adapter
The same behavior as Ali Tekin reported:
"Error: error writing to flash at address 0x0800 at offset
0x"
On 2021-06-17 14:51, ali tekin wrote:
Do you get this warning below, too? Could you post the cfg file?
> Wa
Just checked with latest HEAD on STM32L0538-Disco: Works as expected.
The problem in your case might be there:
On 2021-06-17 14:51, ali tekin wrote:
Warn : target was in unknown state when halt was requested
I'd suggest to do a mass erase, reset option bytes to factory defaults,
power cycle,
On 2021-03-09 12:34, Michael Schwingen wrote:
Is there a documented way to get a *manufacturer* ID in some common
register that can be accessed without prior knowledge about the part?
If
not, I would prefer to shift this decision to the configuration file.
CoreSight ROM tables. Problems are t
Unfortunately I don't know aarch64 target. The main point for the ring
buffer implementation is that there must be a possibility to read/write
the buffer head/tail pointers atomically and concurrently with the
running target
(and of course, to access the buffer itself, too).
On 2021-01-31 22:1
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
On 2021-01-21 05:28, Taylor Stroobosscher via OpenOCD-devel wrote:
What would be the best approach to start here? Does a dedicated
'fslqspi' driver
seem like it would be a worthwhile effort? Would possibly working on
the
previous code be realistic?
If you decide to develop a driver, I'd sugg
The disadvantage of 4235 is programming speed: As the flash chips are
getting larger (16 MBytes is already only moderate size), handling every
single register read/write via the host and debug adapter becomes
unfeasible.
(Similar problem for a verify: Complete readout and comparison on the
host
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
Please note that I'm currently working on some significant changes as
H7, L4+ (and apparently MP1) series suffer from an unpleasant silicon
bug in memory mapped mode ...
On 2019-05-15 14:43, Claudio Lanconelli wrote:
Hello,
can you merge http://openocd.zylin.com/#/c/4321 before next release,
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
Well, with typical values from datasheet: 57*0.08+899*0.0015=5.9085
So approx. 6s is the bottom line dictated by controller hardware. Given
that Eclipse is known to be a bit ... sluggish, your 12s are really not
as bad as one might think initially.
Maybe you could save 1 or 2 seconds by using
These figures are quite surprising. I've made a lot of benchmarks with a
pile of discovery boards, mainly F4 and F7, some L4. Since my focus was
on external spi flash, I did not record the results for the internal
flash, but as far as I recall, both programming *AND* read (via
write_bank , read
Just came across some nasty hex images in ST's CubeMX packages:
STM32Cube_FW_F4_V1.17.0/Projects/STM32469I-Discovery/Demonstrations/STemWin/Binary/STM32469I-Disco_Demo_V1.2.0_FULL.hex
STM32Cube_FW_F4_V1.17.0/Projects/STM32469I_EVAL/Demonstrations/STemWin/Binary/STM32469I_EVAL_Demo_V1.2.0_FULL.hex
The same feature (or even better - single/dual bank selectable by option bytes
...) appears e. g. in the f7 family. So you might compare this with stm32f2x.c
(indeed **f2x**). There more or less variant 1) is used.
---
** [tickets:#148] STM32L0x: flash size and dual bank support**
**Status:**
55 matches
Mail list logo
