On Tue, Feb 27, 2018 at 7:03 AM, Christopher Head <open...@chead.ca> wrote: > On Mon, 26 Feb 2018 16:23:08 -0800 > Christopher Head <open...@chead.ca> 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.
Hi Christophe, I had something similar in my TODO list, but never got time to code it down. I agree that 16 bit parallelism is NOT the safest case. It is supposed to fail writing in flash if the device is powered at 1.8V The right setup should use 8 bit as default, compatible with all the possible voltage ranges. But this would increase the programming time in 3.3V systems. The first step in fixing this is to have write width selectable as 8, 16, 32 or 64 bits. I prefer let the user select the width (not the voltage) because the relationship width<=>voltage could be different in future devices. Actually some JTAG dongle is able to read the voltage of the target, but this feature is not always present and, depending on the setup, the wire that senses the voltage could be unconnected. I would not rely on the JTAG to know the target voltage. > Having thought it over a little more, perhaps we could use the bus > width parameter to the flash bank command for this purpose instead of > a new stm32f2x subcommand? Then add a settable variable which gets > passed through the shipped target config files? User should set the width in the board file (depending on board voltage) using a variable that is then passed to the target file. In the target file the variable should be checked and get a reasonable default if it is not set. Should we keep 16 bits for backward compatibility or 8 bits for safety reason? Then, how to pass the value: sub-command or "flash bank" parameter or even "target" parameter? I personally prefer adding it to "flash bank". We could easily handle the case of banks that require different value (I do not see this case today). But I would not reject other proposals, if well motivated. 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 for it. Best Regards, Antonio > -- > Christopher Head ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
