Hi there.
Just to let know that trying to write in flash a 79 740 bytes file, I’ve seen that the last 4 bytes of the file are not copied: they are zero’d instead. Quick fix until I find the problem: add some stuff at the end of the file to flash so nothing is lost ;-(
Bernard
Hello Bernard,
thanks for noticing this. I’ve fixed the problem already, and I’ll commit this fix together with drastically increased str7x write performance later today.
Regards,
Dominic
Thanks Dominic for your perpetual support 
Summary of other problems found with openocd/str7 (what about setting some bug tracking system? On Savannah for instance?):
Only one flash bank defined when the MCU has two. Side effects: one can’t do ‘flash erase 0 0 9’ since openocd sectors 8 and 9 are in MCU bank 1 and the MCU refuses to erase sectors in MCU bank 0 and 1 at the same time.
Always clear FLASH_ER before any kind of flash query.
GDB is not able to process some ‘monitor’ commands: for instance ‘monitor flash erase 0 0 7’ breaks gdb with ‘.gdbinit:9: Error in sourced command file: Replay contains invalid hex digit 116’.
Features missing:
To the md* commands (mdb, mdw, etc.) could show ascii characters on the right of the hexadecimal listing.
a ‘search’ feature allow one to give hex data or ascii, a starting address and an ending address, for searching data in memory.
support of ‘readline’.
For the flash/write speed increase, someone at my company is also working on it, using the following scheme:
the code that will write to the flash is written in C, compiled by arm-elf-gcc, converted to a uint8_t array and sent to the target. The script that does this conversion is a small shell script. using C will allow one to re-use this system to a new target much quicker than it was to get cfi.c modified to work for STR7 with ASM code.
Instead of using registers to pass parameters, parts of the array are modified. The location to modify are given also by the script that makes the array.
registers are saved/restored, so one can run a program, halt it, modify the flash, then resume execution (well we hope to have that result :-)). This is nice when one part of the flash holds parameters for the application: no need to rerun completely the target program.
Sorry Dominic, maybe yet another one
I have a 74 bytes file that I want to flash write to MCU bank 1 (openocd bank 8 with the current bank/sector numbering)
I can’t write it to flash using:
flash write 0 filename 0xC0000
or
flash write 0 filename 0x400C0000
In either case, openocd replies with:
destination is out of flash bank (offset and/or file too large)
Maybe I’m doing the query incorrectly?
Bernard
Hello Bernard,
I’ve just committed my changes to the SVN repository.
The OpenOCD now correctly handles trailing bytes (non (dword) 8-byte aligned), and is now able to program the 256kb flash of a STR711 in about 5.5 seconds (~45kb/s) using a FT2232 based JTAG interface.
I’ll look into the issues with the second str7 flash bank tomorrow. The current code just checks offset + size against the size of the bank, which only takes the first str7-bank into account. I’ll change this to check the addresses against the sector table.
Regards,
Dominic
Super cool! My application flashing time went from 242 seconds to 3 seconds or so!
Many Thanks!
Bernard
The second flash bank on the STR71x devices is now working as expected, too. The OpenOCD ensures that the flash writing target falls within valid flash sectors, i.e. if it lies within bank0 or bank1.
The flash erase code checks which banks the selected sectors belong to, and uses two accesses to if sectors on both banks are specified.
I’ve been able to erase the flash without problems using GDB’s monitor facility. If this problem persists, please send me a OpenOCD logfile (run with -d -l ) and the GDB output to Dominic.Rath gmx.de.
Readline support is intentionally missing, if you mean having OpenOCD interactively handle console input/output. I’ve always wanted to be able to port the OpenOCD to a SBC, and the telnet interface provides a flexible way of accessing the OpenOCD both on the local host and on a remote host or SBC. Besides, readline would probably just add to the amount of non-portable (not easily portable) code.
The improved md[bhw] output and a search feature would be nice, and I’d be happy to add any patches, but I don’t think I’ll get around writing this myself in the near future.
Regards,
Dominic
Hi Dominic.
I was away last week hence the delay to comment on your recent changes about the STR7. There is still one problem: if you flash the MCU once, you can"t flash it again without restarting openocd. It says:
Error: str7x.c:618 str7x_write(): flash writing failed with error code: 0x0
I don’t think that it comes from error flags from the MCU since the result is the same if you reset it before trying a new ‘flash write’. May be I’ll have time today to look at the origin of the problem.
Bernard