CommunityGD32Cores / platform-gd32

PlatformIO platform for ARM-based GD32{F,E,L,W} chips. Work in Progress!
64 stars 28 forks source link

Support for Zephyr framework #34

Open mamins1376 opened 2 years ago

mamins1376 commented 2 years ago

upstream ststm32 platform supports this - seems like adding the build script is possible?

maxgerhardt commented 2 years ago

Interesting, at the time I looked at this, Zephyr didn't support anything Gigadevice related, but now it seems to have better support for some boards: See "gd32" in https://github.com/zephyrproject-rtos/zephyr/tree/main/boards/arm.

Which boards / chips exactly would like to see supported?

mamins1376 commented 2 years ago

Basically I'm just treating the mcu like a STM32 from Zephyr's viewpoint. e.g. with custom board and soc trees which refer to STM since the support is already there; but having GD32 platform directly supporting Zephyr would make the whole a bit simpler.

The debugger and uploader are not dependent on explicit Zephyr support, PIO support would make it possible out of the box.

maxgerhardt commented 2 years ago

I'm just treating the mcu like a STM32 from Zephyr's viewpoint

And what mapping from GD32 to STM32 are you using there?

mamins1376 commented 2 years ago

GD32F330C8 -> STM32F301C8 for now. subject to change.

maxgerhardt commented 2 years ago

Hm, looking at the memory map for GD32F303xx page 15 and STM32F103C8 page 51, they are different in e.g. already GPIOA peripheral address. But RCC, UART, I2C and TIM are a match. Did you test GPIO control with the Zephyr APIs and it failed to work?

What Zephyr board config would the STM32F301C8 be? Because I don't see that in the aforementioned boards, and https://github.com/platformio/platform-ststm32/tree/develop/boards doesn't even list the F301C8, either as a generic chip or on a nucleo / discovery board.

mamins1376 commented 2 years ago

I just copied STM32F302 soc config and modified it. Not sure if it is going to work.

But what I'm stuck on at the moment is trying to get OpenOCD to work:

target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
** Programming Started **
Warn : STM32 flash size failed, probe inaccurate - assuming 128k flash
Error: stm32x device programming failed
Error: failed erasing sectors 0 to 16
embedded:startup.tcl:1070: Error: ** Programming Failed **
in procedure 'program' 
in procedure 'program_error' called at file "embedded:startup.tcl", line 1135
at file "embedded:startup.tcl", line 1070
*** [upload] Error 1

openocd.cfg:

source [find interface/stlink.cfg]

set CPUTAPID 0x2ba01477

set FLASH_SIZE 0x10000

source [find target/stm32f1x.cfg]

If this starts working I might switch to something like STM32F103 for the mapping.

Any ideas?

maxgerhardt commented 2 years ago

I treat my GD32F303CC with the stm32f1x.cfg config file. Sources like https://www.eevblog.com/forum/microcontrollers/psa-gd32f303-is-not-a-drop-in-substitute-for-stm32f303/ also say its more a STM32F103. Your current problem might actually be flash protection and I've had that once too, I used the https://www.st.com/en/development-tools/stsw-link004.html and changed the option bytes to turn of the readout protecion (RDP) and did a mass-erase, then it worked.

mamins1376 commented 2 years ago

Yes, Readout-protection was the case. Thank you.

Based on what you said and other sources, seems like it's better to treat it like a F103 instead. I'd probably go with that.