Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

> "Matthias" == Matthias Welwarsky writes: Matthias> You will always have the best performance if you carefully Matthias> tweak your write speed so that you reach optimum performance Matthias> without ever producing a WAIT response. HLA adapters or

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

Yes, I used the default setting of 8000. However I think I have now figured out where the WAITs came from, and it’s not because the clock frequency was inherently too high. Rather, it is because the reset-init handler for the chip does the adapter_khz change. So on a two-chip chain, after the

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On 13.03.2018 21:14, Christopher Head wrote: On March 13, 2018 12:21:47 PM PDT, Tomas Vanek via OpenOCD-devel wrote: Obviously faster DAP WAIT handling on USB HS. The question remains: why are you getting DAP WAITs with algo, is the reason different

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On March 13, 2018 12:21:47 PM PDT, Tomas Vanek via OpenOCD-devel wrote: >Obviously faster DAP WAIT handling on USB HS. >The question remains: why are you getting DAP WAITs with algo, is the >reason >different adapter FT2232H vs FT2232C (should not be

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On 13.03.2018 19:04, Christopher Head wrote: OK, here are my test results. All are taken on a JTAG chain with two STM32F745 chips, using an Olimex ARM-USB-TINY-H. In all cases the data is written to the second chip in the chain and is 473 kilobytes using the command “flash write_bank 1

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

OK, here are my test results. All are taken on a JTAG chain with two STM32F745 chips, using an Olimex ARM-USB-TINY-H. In all cases the data is written to the second chip in the chain and is 473 kilobytes using the command “flash write_bank 1 filename.bin”. In all cases the default clock is

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On 13.03.2018 10:40, Uwe Bonnes wrote: Just for reference: Can anybody test what number gdb reports for the "load" command in that circumstances? Thanks Good point, Uwe. Here you go: FT2232, JTAG, STM32F722-nucleo: > reset init ... > adapter_khz adapter speed: 3000 kHz > dap memaccess memory

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On Dienstag, 13. März 2018 01:32:24 CET Tomas Vanek via OpenOCD-devel wrote: > On 12.03.2018 21:53, Christopher Head wrote: > > On March 10, 2018 11:25:15 PM PST, Tomas Vanek via OpenOCD-devel wrote: > I got much worse results with DAP WAIT on a slow old Intel Atom single > core industrial PC: >

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

> "Tomas" == Tomas Vanek via OpenOCD-devel > writes: ... >> reset init Tomas> ... >> adapter_khz Tomas> adapter speed: 3000 kHz >> dap memaccess Tomas> memory bus access delay set to 8 tck >> targets f7.cpu flash

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On 12.03.2018 21:53, Christopher Head wrote: On March 10, 2018 11:25:15 PM PST, Tomas Vanek via OpenOCD-devel wrote: I wouldn't call this case as an obscure one. The reason could be insufficient device clock rate, not very high adapter_khz. Anyway all

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On March 10, 2018 11:25:15 PM PST, Tomas Vanek via OpenOCD-devel wrote: >I wouldn't call this case as an obscure one. The reason could be >insufficient device clock rate, >not very high adapter_khz. Anyway all these cases could be solved by >configuring

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On March 1, 2018 2:55:37 AM PST, Tomas Vanek via OpenOCD-devel wrote: >I meant possible errors induced from sticky state to target handling. >Maybe nonsense, ok. >Christopher, did you get algo timeouts and unpowered dbg regions on >FTDI Yes, I got those

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On 01.03.2018 10:25, Matthias Welwarsky wrote: WAITs are very strange. It looks like the stalled access to flash blocks also JTAG access to RAM. And SWD access doesn't suffer this silicon bug... who knows... maybe some NOPs in algo busy wait loop would fix it. BTW The programming algo should

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On Donnerstag, 1. März 2018 07:27:49 CET Christopher Head wrote: > On Thu, 1 Mar 2018 00:12:12 +0100 > > Tomas Vanek wrote: > > We should also focus to a question why algo flashing is broken on > > FTDI. Some non STM devices (e.g. Kinetis) work with very similar

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On Thu, 1 Mar 2018 00:12:12 +0100 Tomas Vanek wrote: > We should also focus to a question why algo flashing is broken on > FTDI. Some non STM devices (e.g. Kinetis) work with very similar algo > just perfectly on FTDI or any other adapter. Sure. If someone could

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On Mittwoch, 28. Februar 2018 21:51:29 CET Christopher Head wrote: > I’ll be completely honest here: the reason I tried doing this is because the > algorithm approach *broke* with the FTDI adapter, not because I wanted to > improve speed. It kept issuing messages either timeout waiting for >

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On February 28, 2018 8:10:09 AM PST, Andreas Bolsch wrote: >To be sure I just did the following tests (openOCD, current head, >integrated ST-Link v2-1, 4 MHz SWD clock): >nucleo-f767zi, 2 MByte random data: prog: 140 kBytes/s, read: 150 >kBytes/s >disco-f412g, 1 MByte

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

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 ,

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

> "Freddie" == Freddie Chopin writes: ... Freddie> Reference Manual is misleading here, but datasheet is even more Freddie> confusing. If you look at any STM32F7 datasheet, it says that Freddie> max Programming voltage Vprog for 16x and 8x parallelism is 3.6

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On Dienstag, 27. Februar 2018 23:23:47 CET Christopher Head wrote: > On February 27, 2018 2:42:25 AM PST, Matthias Welwarsky wrote: > >I'm guessing that the BUSY check was done to explicitly to avoid a JTAG > >WAIT, > >which was an error condition not long ago. It

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On February 27, 2018 2:42:25 AM PST, Matthias Welwarsky wrote: >I'm guessing that the BUSY check was done to explicitly to avoid a JTAG >WAIT, >which was an error condition not long ago. It might still break with >SWD. Ah, I didn’t know that WAIT was ever

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On February 27, 2018 1:10:19 AM PST, Antonio Borneo wrote: >Regarding your proposal to get rid of the write algorithm, I'm a >little sceptical it is not needed. >I would like to see the optimized direct programming code and get some >performance measurement before going

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On February 27, 2018 1:28:01 AM PST, Freddie Chopin wrote: >5.3.13 Memory characteristics >Table 48. Flash memory programming >(numbers don't have to match your version of datasheet exactly) Oh, that is very interesting. I missed that table the first time. When I looked

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On Tue, Feb 27, 2018 at 10:28 AM, Freddie Chopin wrote: > On Mon, 2018-02-26 at 16:23 -0800, Christopher Head wrote: >> Hi all, >> I was looking into an issue with Flash programming on the STM32F7. I >> discovered some quite odd results. >> >> First, I discovered that

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On Dienstag, 27. Februar 2018 01:23:08 CET Christopher Head wrote: > Second, I discovered that, in both algorithm-driven mode and direct > programming mode, the loop writes to CR, then writes one halfword of data > to the target address, then checks BSY and the error flags in SR. However, > this

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On Mon, 2018-02-26 at 16:23 -0800, Christopher Head wrote: > Hi all, > I was looking into an issue with Flash programming on the STM32F7. I > discovered some quite odd results. > > First, I discovered that OpenOCD always uses 16-bit parallelism. > There is a comment at the top of stm32f2x.c

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On Tue, Feb 27, 2018 at 7:03 AM, Christopher Head wrote: > On Mon, 26 Feb 2018 16:23:08 -0800 > Christopher Head wrote: > >> 2. Allow the user to set the parallelism level with a new stm32f2x >> subcommand, since only the board config knows what VDD is being

Re: [OpenOCD-devel] STM32F2/4/7 Flash programming

On Mon, 26 Feb 2018 16:23:08 -0800 Christopher Head wrote: > 2. Allow the user to set the parallelism level with a new stm32f2x > subcommand, since only the board config knows what VDD is being > supplied. Having thought it over a little more, perhaps we could use the bus

[OpenOCD-devel] STM32F2/4/7 Flash programming

Hi all, I was looking into an issue with Flash programming on the STM32F7. I discovered some quite odd results. First, I discovered that OpenOCD always uses 16-bit parallelism. There is a comment at the top of stm32f2x.c stating that this was chosen for compatibility with the widest possible