Menu
▾
▴
Re: [OpenOCD-devel] GigaDevice GD32E230 support
|
From: Antonio B. <bor...@gm...> - 2021-03-10 22:03:58
|
Could you post the whole dump of the GD32E230's ROM table? You can use CMSIS-DAP with openocd command 'dap info' Antonio On Wed, Mar 10, 2021 at 10:21 PM Michael Schwingen <mi...@sc...> wrote: > > On 09.03.21 14:00, Andreas Bolsch wrote: > > 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 ... > > That seems like a good idea. But: > > After Uwe Bonnes' recommendation, I tested using backmagic. The results: > > AP Designer JEP106 (w/o parity) > > EFM32TG 0x673 Bank 7/0x73 = Energy Micro > XMC4500 0x41 Bank 0/0x41 = Infineon > STM32G031 0x20 Bank 0/0x20 = ST > MSP432 0x17 Bank 0/0x17 = TI > SAMD10 0x1F Bank 0/0x1F = Atmel > GD32E230 0x43B Bank 5/0x3B = ARM (!) > > (AP designer IDs are from Jedec JEP106, with the first nibble being (bank number - 1)) > > It seems GigaDevice did not copy from ST, but nevertheless entered the wrong ID (from ARM). > GigaDevice has two IDs listed in JEP106 (0x648 and 0x751) which they could have used ... > > And yes, there are buggy ROM tables: I have an old LM3S6819 board > (from before they were bought by TI) which reports "0" as AP Designer. > > I lean towards not doing auto-detection - there may be more devices with buggy ROM tables in the future. > Having a separate config file (with the correct driver or flag specified) for such a device is not such a big hassle and avoids any ambiguities. > > Comments? > > cu > Michael > > _______________________________________________ > OpenOCD-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openocd-devel |
