Re: [OpenOCD-devel] GigaDevice GD32E230 support

[Tommy M. <tom...@ho...>]

Is this of relevance to your query?

https://www.mail-archive.com/ope...@li.../msg12475.html

Are GD actually reusing STM IDCODEs (including manufacturer ID) verbatim? :-o


________________________________
From: Michael Schwingen <mi...@sc...>
Sent: Monday 8 March 2021 19:12
To: Ope...@li... <Ope...@li...>
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
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openocd-devel