Am 01/25/2012 07:10 AM, schrieb Luke: >>>>> 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? If the code is mostly identical, it makes sense to factor out the common part and have it only once in the source.
You may either a) modify em357.c to support all chips (which would mean renaming it afterwards might be in order) b) move the common code from em357.c to some separate file, leaving em357.c a mostly empty wrapper that calls the common code with the right parameters, and add stm32w.c which also calls the common code with flexible parameters. Auto-probing the parameters from the device would be great it it can be done, but specifying them in the config file would also be OK (and probably easier to implement). What is (IMHO) not OK is to simply copy the complete em357.c file and modify it for stm32w, duplicating lots of code. cu Michael ------------------------------------------------------------------------------ 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
