Is this of relevance to your query? https://www.mail-archive.com/[email protected]/msg12475.html
Are GD actually reusing STM IDCODEs (including manufacturer ID) verbatim? :-o ________________________________ From: Michael Schwingen <[email protected]> Sent: Monday 8 March 2021 19:12 To: [email protected] <[email protected]> Subject: [OpenOCD-devel] GigaDevice GD32E230 support (re-send from correct mail address) Hi, I am currently starting to work on a project that uses a GD32E230 CPU (due to ST's inability to ship parts in the required volume for the next year or so :-(). The older GD32 parts were basically 1:1 ST-compatible clones. However, the GD32E230 deviates from this: it has a Cortex-M23 core, but the peripherals seem to be STM32F0-like. I have a quick hack to support this in flash/nor/stm32f1x.c, but this is definitely not submittable as-is. The problem is that stm32f1x.c uses the CPU core ID to distinguish the different supported variants. While this works currently (there is no Cortex-M23 ST part), this may collide in the future when new ST parts arrive. I am looking for advice on the best way to add GD32 support - I would like to not duplicate the complete driver, and use as much common code as possible - however, that means an additional selector is needed to distinguish ST and GD parts. My current idea is to add an additional parameter to the ST flash driver so that a GD32 config file can specify the used variant, and the driver can then do the flash parameter lookup based on that. Does that sound OK, or are there better approaches? cu Michael -- Some people have no respect of age unless it is bottled. _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
_______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
