Re: [OpenOCD-devel] GigaDevice GD32E230 support

[Michael S. <mi...@sc...>]

On 09.03.21 15:14, Uwe Bonnes wrote:
> Andreas Bolsch writes:
>> On 2021-03-09 12:34, Michael Schwingen wrote:
>>> Is there a documented way to get a *manufacturer* ID in some common
>>> register that can be accessed without prior knowledge about the part? 
>>> If
>>> not, I would prefer to shift this decision to the configuration file.
>> CoreSight ROM tables. Problems are that even there GD might have reused 
>> ST's, and
>> there might be even devices without or with buggy ROM tables ...
>>
> At least the GD32F1 and other STM32F103 clones have genuine ARM
> numbers in the Romtable PIDR. Furthermore, they have newer core
> revisions.  In Blackmagic I accepted code for the GD32E230 in the
> stm32f1 code paths. I did not test due to missing test target, but it
> indicates that the romtable number are not the ST romtable numbers.

OK, I will check that. However, detecting flash types based only on core
revision (aka "this is a newer core, so this must be a GD32 and not a
STM32") is not the way to go IMHO - there needs to be some kind of
really unique vendor ID for solid auto-detection to work.

> If Michael could test against BMP/hosted and confirm  GD32E230
> detected and working, I 'd be gratefull. With an Stlink/Jlink/CMSIS
> Dap/Ftdi adpater connected the right way, this would be "blackmagic
> -t" for a first test, after compiling in src "make PROBE_HOST=hosted"

Sure - let's move that off-list.

I currently only have a single GD32E230C-Start board, which is limited
to using the onboard CMSIS-DAP probe, but I should get sample parts soon
- I plan to solder some on my breakout boards, and then I can attach a
BMP debugger and test.

cu

Michael