>>>> Also if i remember correctly the flash controller is not exactly the >>>> same as the stm32f1x, may be worth checking the em357 driver. >>>> The em35x family are the same device as the stm32w.
I'm trying to get started on the stm32w version and I was hoping to start from em357.c as a template of sorts. After digging into the details of the STM32W flash programming datasheet and comparing the registers in there with the registers locations defined in em357.c and the corresponding Ember datasheet, I have determined that the flash memory locations and definitions for *every* flash control register in all four versions of the stm32w (64kb, 128kb, 192kb, 256kb) are identical. So, it seems that the em357 driver should have a lot of overlapping code with the stm32w driver, but with two caveats: number of pages and page size. The em357.c file is hard coded to have 96 2kb pages. This hard coding of the page size and number of pages occurs in a function called em357_probe, but obviously no probing is going on. This seems fine for a driver file that is only for one specific version of a chip, but it raises issues with other chips that are nearly identical except for flash capacity. In the STM32W devices, the 64 and 128 kb devices use 64 or 128 1kb pages, while the 192 and 256kb devices use 96 or 128 2kb pages. In the Ember devices, there are fewer options, either 128 or 192kb, with either 64 or 96 2kb pages. So a few questions: 1) From an addressing and storage capacity point of view, the 128 and 192kb versions of the STM32w seem to map directly to the Em351 and Em357 devices, but I don't know enough about flash memory to know whether it matters that in the 128kb Em351 there are 64 2kb pages vs. 128 1kb pages in the 128kb version of the stm32w. 2) Does it make sense to extend/modify the em357.c file to cover all versions of this family of chips? Barring the page size & number of page differences, it seems like these chips are identical and from what I can tell they were developed somewhat collaboratively between ST and Ember. Or does it make more sense to create a new driver, stm32w, that handles all four (or fewer) versions of the stm32w? I don't know how hard it is to probe these devices to determine automatically which one is which (manufacturer id or something?), or if this could be relied upon from the user tcl .cfg files to set the appropriate options (i.e., 64kb, 128kb, 192kb, or 256kb of flash) in the driver, but it seems like it would be nice to put all this logic into one file since they are all so similar. This way, there are fewer driver files to maintain if the structure of OpenOCD changes in some way that requires changes in the driver files. I'd really like to get this driver working since I have 4 stm32w development boards that are sitting on my desk and need some loving from my JTAG cable :) Thoughts? Thanks, ~Luke ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
