search

CommunityGD32Cores / ArduinoCore-GD32

Arduino core for GD32 devices, community developed, based on original GigaDevice's core
Other
92 stars 33 forks source link

When will GD32E230C be supported? #55

Closed NathanKuo0821 closed 2 years ago

NathanKuo0821 commented 3 years ago

I have been waiting for GD32E230C to support Arduino , Is there a plan to support? schedule? Very thanks.

maxgerhardt commented 3 years ago

There isn't a hard schedule since I'm doing the board-support part of this project as a hobby, but in the new year we expect to quickly add support for all not-yet support microcontrollers.

The GD32E230C is supported with the standard SPL framework (use e.g. the board = genericGD32E230C6, we have the board definition, and upload is currently possible with the black magic probe (https://github.com/CommunityGD32Cores/platform-gd32/issues/18), and soon with OpenOCD and e.g. STLink when a new OpenOCD version releases.

maxgerhardt commented 3 years ago

Meh actually the E230 series is so similiar to the F1x0 series for which we can autogenerate the pinmaps, I'll give it a quick try.

maxgerhardt commented 3 years ago

I've just added GD32E230C series chips to the Arduino core and variants, see here. All untested.

Please use PlatformIO for testing. Open a CLI and execute pio platform update gd32 to update to the latest Platform-GD32 version and Arduino core if you haven't installed it before, or use pio platform install https://github.com/CommunityGD32Cores/platform-gd32.git if you've never installed it. You should then be able to create a GD32E230C(4 / 6 / 8) with the framework set to Arduino.

Use the code from e.g. https://github.com/CommunityGD32Cores/gd32-pio-projects/tree/main/gd32-arduino-blinky to test UART (output on PA2) and LED (PC13). The code should compile.

OpenOCD upload is however not working right now -- what upload method are you using? STLink? GDLink? Black magic probe? ..

NathanKuo0821 commented 3 years ago

Dear Sir, Thank you very much for your GD32 project and quick response. I am using the EVM board of gd32e230c-start such as https://www.amazon.de/-/en/dp/B07YR72M9T , Is the current board data applicable? And upload code using CMSIS-DAP. image

Thank you again for your contribution

Nathan Kuo

maxgerhardt commented 3 years ago

It's possible if the new OpenOCD support for GD32E230x works.

I've added an explicit new board definition (gd32e230c_start) to platform-gd32 and custom-compiled the latest OpenOCD in https://github.com/maxgerhardt/pio-openocd-gd32.

Can you please do the following:

  1. Open a CLI and execute pio platform update gd32 if you have previously used platform-gd32.
  2. Clone the repository https://github.com/maxgerhardt/pio-gd32e230c-start
  3. Open the project in VSCode + PlatformIO using the normal PIO Home -> Open Project way
  4. Use the project environment switcher to switch the new project and its gd32e230c_start environment
  5. Use the project task "Build". It should compile.
  6. Use the project task "Advanced -> Verbose Upload".

If the last step fails, please post the complete output of the terminal.

For all of these steps you need to have Git installed.

NathanKuo0821 commented 3 years ago

Dear Maximilian Gerhardt,

The log is as follows, upload code seems to be unsuccessful, any suggestions?

Executing task in folder GD32E230: C:\Users\skyke.platformio\penv\Scripts\platformio.exe run --target upload <

Processing gd32e230c_start (board: gd32e230c_start; framework: arduino; platform: https://github.com/CommunityGD32Cores/platform-gd32.git) ------------------------------------------------------------------------------------------------------------------------------------Verbose mode can be enabled via -v, --verbose option CONFIGURATION: https://docs.platformio.org/page/boards/gd32/gd32e230c_start.html PLATFORM: GD GD32 (1.0.0+sha.e6d262f) > GD32E230C-START (8k RAM, 64k Flash) HARDWARE: GD32E230C8T6 72MHz, 8KB RAM, 64KB Flash DEBUG: Current (cmsis-dap) External (blackmagic, cmsis-dap, jlink, sipeed-rv-debugger, stlink) PACKAGES:

swd 0 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x080005f8 msp: 0x20002000 Programming Started Programming Finished Verify Started Verified OK Resetting Target shutdown command invoked =================================================== [SUCCESS] Took 5.47 seconds ===================================================

Nathan Kuo

NathanKuo0821 commented 3 years ago

Dear Maximilian Gerhardt, I changed the upload method to jLink and it is connected to the SWD pin , it still seems to fail.

Executing task in folder GD32E230: C:\Users\skyke.platformio\penv\Scripts\platformio.exe run --target upload <

Processing gd32e230c_start (board: gd32e230c_start; framework: arduino; platform: https://github.com/CommunityGD32Cores/platform-gd32.git) ------------------------------------------------------------------------------------------------------------------------------------Verbose mode can be enabled via -v, --verbose option CONFIGURATION: https://docs.platformio.org/page/boards/gd32/gd32e230c_start.html PLATFORM: GD GD32 (1.0.0+sha.e6d262f) > GD32E230C-START (8k RAM, 64k Flash) HARDWARE: GD32E230C8T6 72MHz, 8KB RAM, 64KB Flash DEBUG: Current (cmsis-dap) External (blackmagic, cmsis-dap, jlink, sipeed-rv-debugger, stlink) PACKAGES:

J-Link Command File read successfully. Processing script file...

J-Link connection not established yet but required for command. Connecting to J-Link via USB...O.K. Firmware: J-Link ARM-OB STM32 compiled Aug 22 2012 19:52:04 Hardware version: V7.00 S/N: 20090928 License(s): RDI,FlashDL,FlashBP,JFlash,GDB VTref=3.300V Target connection not established yet but required for command. Device "GD32E230C8" selected.

Connecting to target via SWD Found SW-DP with ID 0x1BA01477 DPv0 detected Scanning AP map to find all available APs AP[1]: Stopped AP scan as end of AP map has been reached AP[0]: AHB-AP (IDR: 0x24770011) Iterating through AP map to find AHB-AP to use AP[0]: Core found AP[0]: AHB-AP ROM base: 0xE00FF000 CPUID register: 0x412FC231. Implementer code: 0x41 (ARM) Found Cortex-M3 r2p1, Little endian. Identified core does not match configuration. (Found: Cortex-M3, Configured: Cortex-M23) FPUnit: 6 code (BP) slots and 2 literal slots CoreSight components: ROMTbl[0] @ E00FF000 ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB000 SCS ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM ROMTbl[0][4]: E0040000, CID: B105900D, PID: 003BB923 TPIU-Lite Cortex-M3 identified. T-bit of XPSR is 0 but should be 1. Changed to 1. PC = 00000000, CycleCnt = 03F67D9D R0 = 20000624, R1 = 0000AAAA, R2 = 200006B4, R3 = 08000200 R4 = 20000624, R5 = 2000067C, R6 = 2000067C, R7 = 000000FF R8 = 2122D802, R9 = 04280412, R10= 28043142, R11= 02001A06 R12= 200005A8 SP(R13)= FFFFFFE0, MSP= FFFFFFE0, PSP= 21303004, R14(LR) = FFFFFFF9 XPSR = 01000003: APSR = nzcvq, EPSR = 01000000, IPSR = 003 (HardFault) CFBP = 00000000, CONTROL = 00, FAULTMASK = 00, BASEPRI = 00, PRIMASK = 00 FPU regs: FPU not enabled / not implemented on connected CPU.

Downloading file [.pio\build\gd32e230c_start\firmware.bin]... Comparing flash [100%] Done. Erasing flash [100%] Done.

** Error: Timeout while calculating CRC, RAMCode did not respond in time. (PC = 0x04280412, CPSR = 0x2122D802, LR = 0x01000000)!Failed to erase sectors 0 @ address 0x08000000 ((erase error)) Failed to erase sectors.

Unspecified error -1

Reset delay: 0 ms Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit. Reset: Halt core after reset via DEMCR.VC_CORERESET. Reset: Reset device via AIRCR.SYSRESETREQ. T-bit of XPSR is 0 but should be 1. Changed to 1.

Script processing completed.

Nathan Kuo

maxgerhardt commented 3 years ago 
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080005f8 msp: 0x20002000
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked
========== [SUCCESS] Took 5.47 seconds ==========

Your upload with the CMSIS-DAP standard configuration looks good. The JLink upload does not look good, because it says

Found Cortex-M3 r2p1, Little endian. Identified core does not match configuration. (Found: Cortex-M3, Configured: Cortex-M23)

The GD32E230C8 is definitely a Cortex-M23 part (https://www.gigadevice.com/microcontroller/gd32e230c8t6/) and not a Cortex-M3. Did you connect the JLink to a different microcontroller?

What I would suggest is that you go back to the standard CMSIS-DAP upload (no JLink), but change the code of project (src\main.cpp) to the more simple

#include <Arduino.h>
#define LED PA7

void setup(){
    pinMode(LED, OUTPUT);
}

void loop(){
    digitalWrite(LED, LOW);
    delay(500);
    digitalWrite(LED, HIGH);
    delay(500);
}

and, to the original platformio.ini, add

debug_tool = cmsis-dap
debug_init_break = tbreak Reset_Handler

then start a debug session (Debugger sidebar -> make sure "PIO Debug (gd32e230c_start)" is selected -> press play button).

Does the firmware then upload and halt in the Reset_Handler? Can you step through line-by-line using the debug controls and see in which line it crashes? Does it reach main()? (Set breakpoints further down in the assembly code and press play to skip over loops in the startup code).

NathanKuo0821 commented 3 years ago

After flash the code as below, the LED1 PA7 still not working , I also recorded a few videos, can you help me see what's wrong with my environment? Thanks.

https://drive.google.com/file/d/11OsIg0DLUIanU-olDO7gNXIqcU2EiIE6/view?usp=sharing https://drive.google.com/file/d/15HTFfaTL-UWvedAp5kEYTccTIXB0voe_/view?usp=sharing

`#include

define LED PA7

void setup(){ pinMode(LED, OUTPUT); }

void loop(){ digitalWrite(LED, LOW); delay(500); digitalWrite(LED, HIGH); delay(500); }`

Nathan Kuo

maxgerhardt commented 2 years ago

Okay thanks for the videos, these clearly show that uploading & debugging works, that the code reaches the loop() function and can execute it multiple times, but that the LED stays turned off. So a lot is working but not everything.

In the meantime I've ordered a GD32E230C-START board myself so that I have GD32E230 hardware -- though this board will only arrive in about a month.

I have two requests:

  1. Please have a look at the GD32E230C-START schematics in conjuction with the datasheet page 12, Figure 2-2. The schematic says the LED1 is connected to the resistor R25 which is connected to PA7. The datasheet shows where PA7 pin is physically on the chip (physical pin 17). Can you double check with a multimeter, when the board is turned off, that the PA7 pin of the chip has continuity to the R25 resistor, and then from the resistor to LED1, and from LED 1 to GND? Just want to check whether the schematic is correct or whether PA7 is the wrong pin.
  2. Can you please try the following PlatformIO project which uses SPL instead of the Arduino core: https://github.com/maxgerhardt/pio-gd32e230c-spl-blinky. Please make sure to again use the project environment switcher to select the new project and environment after you've imported the project. Does this project blink the LED correctly?
NathanKuo0821 commented 2 years ago

This project is working :https://github.com/maxgerhardt/pio-gd32e230c-spl-blinky , the LED1(PA7) is blinking only on the debug mode , but there seems to be a problem with the upload method and it doesn’t work properly. Finally I hope the arduino framework can work normally , do you have any ideas for this? Very thanks.

Nathan Kuo

maxgerhardt commented 2 years ago

Hm okay if SPL Blinky works in debug mode (I'm not yet sure why it wouldn't work in release mode) then the core likely has a bug. I've looked at the pin-mapping logic and noticed a potential bug (https://github.com/CommunityGD32Cores/ArduinoCore-GD32/commit/f6dc080e2524877910f4b8c6240bfbb7901aab44).

Can you do a pio platform update gd32 in the CLI and try the https://github.com/maxgerhardt/pio-gd32e230c-start example again in debug and release mode?

NathanKuo0821 commented 2 years ago

After do pio platform update gd32 and use https://github.com/maxgerhardt/pio-gd32e230c-start The release and debug modes are still not working, the LED no blink, and the serial port no print log on the strat-c board

Nathan Kuo

maxgerhardt commented 2 years ago

Okay then I'll see why that is when I get hardware and can debug it myself line-by-line. Sadly my order for the board seems to have canceled though because "out of stock", so I'm not sure if I'm getting hardware before the end of the year..

If you have free time and the will to do it you can also help debugging. Especially interesting would be wether when the code enters the digitalWrite() function whether pin is GPIO_PIN_7 (1 << 7 = 128) and port is GPIOA (0x48000000). If that is true there must be some issue with the pin_function() function.

NathanKuo0821 commented 2 years ago

Thank you for your efforts. I don't know how to debug the board data for gd32 , I will wait for your gd32-board is ready :)

Nathan Kuo

djix123 commented 2 years ago

@maxgerhardt - if you're able to generate the pin maps for either a GD32E230F8 or GD32E230K8 I can have a go at debugging the digitalWrite() function.

maxgerhardt commented 2 years ago

Sure, let me have a go at that. Adding the Fx or Kx subseries should be quick.

maxgerhardt commented 2 years ago

I've just added and tested the compilation for E230Kx series in https://github.com/CommunityGD32Cores/ArduinoCore-GD32/commit/45e54cccc0ed2ecd7bb56ef3867a5ebb2739d18f, including your K8.

These are the unmodified autogenerated variant folders, so they have that ANALOG_PINS_LAST macro in the variant.h file which I suspected earlier of screwing up the digital pin mapping -- maybe it still has something to do with it?

You can use https://github.com/CommunityGD32Cores/gd32-pio-projects/tree/main/gd32-arduino-blinky as a base project with the genericGD32E230K8 environment. If that chip happens to sit on one of the Gigadevice made dev-boards, you'll want to be using a total platformio.ini of like 

[env]
platform = https://github.com/CommunityGD32Cores/platform-gd32.git
platform_packages = 
    framework-arduinogd32@https://github.com/CommunityGD32Cores/ArduinoCore-GD32.git
    tool-openocd@https://github.com/maxgerhardt/pio-openocd-gd32/raw/main/tool-openocd-windows_amd64-2.1100.211123.tar.gz

[env:genericGD32E230K8]
board = genericGD32E230K8
framework = arduino
debug_tool = cmsis-dap
upload_protocol = cmsis-dap

Also make sure to open a CLI and execute pio platform update gd32 to make sure you've got all the latest versions.

djix123 commented 2 years ago

Great - I'll git it a try this evening and let you know.

djix123 commented 2 years ago

Ok - so I couldn't wait until this evening! On first look it seems that pinMode( ) isn't setting the output mode correctly. Setting it manually in the setup() function causes the LED to flash (mine's on PB1, but I tried PA7 with same result).

uint32_t *gpiob_ctl = (uint32_t*)0x48000400; 
uint32_t *gpiob_ospd = (uint32_t*)0x48000408;
*gpiob_ctl = 0x04;
*gpiob_ospd = 0x0c;

looking further it seems that pinmap.c isn't completing the configuration because there are board specific sections (protected by #define) and there is not one for the GD32E23x series.

maxgerhardt commented 2 years ago

AAaargh that makes kinda sense... I have pushed commit cbb43a87549ea67de412821d662eb7b051c83f6f, can you again do a pio platform update gd32 and retry with the regular pinMode() and digitalWrite() functions, no register writes?

(If it still doesn't work properly after that it might be that remapping problem with ANALOG_PINS_LAST, try commenting that out in C:\Users\<user>\.platformio\packages\framework-arduinogd32\variants\GD32E230K8_GENERIC\variant.h#L67)

djix123 commented 2 years ago

Great, just updated and confirm that it now works as expected - straight update - no change to ANALOG_PINS_LAST

maxgerhardt commented 2 years ago

Great! I'll add the pinmaps for the remaining E230 boards and close this issue.

If there are issues with other subsystems like Serial, I2C, SPI or whatever, please open new issues to let us know :)

And, as of now, the platformio.ini instructions

platform_packages = 
    framework-arduinogd32@https://github.com/CommunityGD32Cores/ArduinoCore-GD32.git
    tool-openocd@https://github.com/maxgerhardt/pio-openocd-gd32/raw/main/tool-openocd-windows_amd64-2.1100.211123.tar.gz

are critical for getting the latest OpenOCD version that can handle the E230 series. We plan to address this later when we can obtain a compiled version of bleeding-edge OpenOCD for all OSes and upload that to the PlatformIO registry..

djix123 commented 2 years ago

Thanks - will try out Serial, I2C, SPI etc ... over the next few days.

I use an M1 MacBook so have a latest OpenOCD build that handles the E230 on that platform ... if you let me know how you'd like me to package it I can make that available

maxgerhardt commented 2 years ago

if you let me know how you'd like me to package it I can make that available

Oh that would be truely awesome! Are you able to compile it in Intel x64 mode too or only ARM? (Because PlatformIO prefers for Mac that x64 packages are used since they work on x64 and ARM / M1 machines through Rosetta).

The process for packaging would be to first compile OpenOCD, then change-up the folder structure to match what I have in the Windows x64 build above (requires moving some folders up), then in the root of the folder add a package.json with content

{
  "name": "tool-openocd",
  "version": "2.1100.211123",
  "description": "Open On-Chip Debugger. Free and Open On-Chip Debugging, In-System Programming and Boundary-Scan Testing",
  "keywords": [
    "tools",
    "debugger",
    "debug server",
    "uploader"
  ],
  "homepage": "http://openocd.org",
  "license": "GPL-2.0-or-later",
  "repository": {
    "type": "git",
    "url": "https://sourceforge.net/p/openocd/code/ci/master/tree/"
  },
  "system": [
    "darwin_x86_64",
    "darwin_arm64"
  ]
}

(declares package name, version, compatible OSes), and then from a CLI where pio is accessible, navigate to that OpenOCD root folder with the package.json in it and run pio package pack inside it. That shoud generate a single tool-openocd-darwin_.....tar.gz file that we need.

djix123 commented 2 years ago

Ok, great - I can have a go at building the Intel x64 version and pack it up per your instructions. I'll let you know when I've a package for testing.

djix123 commented 2 years ago

Also worth noting, when I have a fresh install of platformio and compile a first 'gd32' project on a Mac I get Error: Could not find the package with 'gd32' requirements for your system 'darwin_x86_64'. A manual install via pio platform install https://github.com/CommunityGD32Cores/platform-gd32.git works and allows successful compiles. Similar message and solution on an M1 Mac as well.

maxgerhardt commented 2 years ago

Our platform-gd32 is not part of PlatformIO's official repository of platforms so when our platform isn't pre-installed and a platformio.ini references platform = gd32, PIO has no idea what to do. What's why the https://github.com/CommunityGD32Cores/gd32-pio-projects always references platform = <git link of platform-gd32> to force installation of that. So in that way the error message is expected.

djix123 commented 2 years ago

Thanks @maxgerhardt - that makes sense.

Quick update on the he openocd build. Realized that a regular build would be non-portable since the linkage appears 'absolute' not 'relative'. Even between Macs of the same architecture this could cause problems, let alone x86_64 vs arm64. Noted that the regular PlatformIO install is based on xpack. (xpack replaces the absolute linkage paths with relative and packages up the additional libraries). I've been trying to build the xpack build box but that has been failing, then saw that the most recent openocd xpack is from Dec 7 ... I'll confirm this is contains the GD32E23x patches. If so, will add the PlatformIO package.json etc ... and make available.

maxgerhardt commented 2 years ago

Oh this reminds of this topic: https://community.platformio.org/t/upload-to-stm32-blackpill-f411ce-fails-over-stlink-v2-incompatible-library-version/24980/9?u=maxgerhardt

So I think Mac OS is really special in this regard and you should look at what the standard PlatformIO openocd packages do with that Linker search path mods.. See https://api.registry.platformio.org/v3/packages/platformio/tool/tool-openocd or specifically https://dl.registry.platformio.org/download/platformio/tool/tool-openocd/2.1100.211028/tool-openocd-darwin_x86_64-2.1100.211028.tar.gz. Since I don't have a Mac I can't verify packages directly sadly.

djix123 commented 2 years ago

Yes, its when I checked the standard platformio openocd install on my Mac so I could follow the directory structure I realized it was 'less than straightforward'. Hence my pivot to the xpack build as the platformio openocd Mac packages is derived from the xpack openocd package.

I'll try and get the new packages build of the weekend - and will then test them on fresh installs. I've access to both an x86_64 and arm64 Mac so can test on both.

djix123 commented 2 years ago

Had a look at https://community.platformio.org/t/upload-to-stm32-blackpill-f411ce-fails-over-stlink-v2-incompatible-library-version/24980/9?u=maxgerhardt

seems a strange one - I've no problem on Mac OS 12.0.1 using the regular platformio openocd to connect to an stm32f411 via a Stlink clone. Just confirmed.

maxgerhardt commented 2 years ago

then saw that the most recent openocd xpack is from Dec 7 ...

Oh I read over that, yes https://github.com/xpack-dev-tools/openocd-xpack/releases seems really good and has the gd32e23x.cfg script in it, so it should be the version we need.. I'll verify on Windows + Linux too after converting them into the folder structure PlatformIO expects with tool-openocd.

djix123 commented 2 years ago

@maxgerhardt - do you have a way I can send you the openocd package? I've built a darwin_x86_64. So far I've tested it on an ARM64 Mac and it works. I replaced the installed version of openocd with a tar xvf of this package and debugged the GD32E230K8 Blinky project with it.

PlatformIO Unified Debugger -> https://bit.ly/pio-debug
PlatformIO: debug_tool = stlink
PlatformIO: Initializing remote target...
xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2021-12-07-19:33)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
hla_swd
0
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : tcl server disabled
Info : telnet server disabled
Info : clock speed 1000 kHz
Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.308502
Info : gd32e23x.cpu: Cortex-M23 r1p0 processor detected
Info : gd32e23x.cpu: target has 4 breakpoints, 2 watchpoints
djix123 commented 2 years ago

tool-openocd-darwin_x86_64-2.1100.2111204.tar.gz

djix123 commented 2 years ago

Just realized its small enough that I could attach it.

maxgerhardt commented 2 years ago

Looking great from the output side, I'll collect Windows + Linux package too and upload them to the PlatformIO registry, then I can reference that in platform-gd32's package.json and we have good out-of-the-box GD32E23x support. Thanks!

djix123 commented 2 years ago

Great - one thing to note, I did adjust the package.json's version entry to 2.1100.211204 to reflect the date that the xpack cut of the official openocd repo was taken (as documented in the compliance page on the xpack openocd page). Let me know if you'd like a different version number and I can update accordingly.

maxgerhardt commented 2 years ago

I've renamed and repacked it as tool-openocd-gd32 which was just fully published. I've switched platform-gd32 to use that package in https://github.com/CommunityGD32Cores/platform-gd32/commit/fbaebc9317c24e77c2ae06c3365d8aba122f639a.

@djix123 Can you again do a pio platform update gd32 to pull the latest version and retry uploading your project with all-standard settings? (no platform_packages regarding OpenOCD)

@NathanKuo0821 Can you also update and confirm https://github.com/maxgerhardt/pio-gd32e230c-start is now uploading and working (with LEDs) out of the box?

djix123 commented 2 years ago

Confirmation new verision of openocd downloads automatically for gd32:

Processing genericGD32E230F8 (board: genericGD32E230F8; framework: arduino; platform: https://github.com/CommunityGD32Cores/platform-gd32.git)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Tool Manager: Installing communitygd32cores/tool-openocd-gd32 @ ~2.1100.0
Downloading  [####################################]  100%
Unpacking  [####################################]  100%
Tool Manager: tool-openocd-gd32 @ 2.1100.211207 has been installed!
Verbose mode can be enabled via `-v, --verbose` option

@maxgerhardt - that's a coincidence! - I just did that as I was about to look at the Arduino peripherals: e.g. Serial, SPI etc ...

djix123 commented 2 years ago

Ok, so Serial works fine (by fine meaning default settings, I've tried nothing exotic) and so does SPI, but to get the Arduino framework to compile I needed to patch drv_spi.c since the the GD32E230 does not have an SPI2.

I've cut/pasted the git diff below. I don't think this is the necessarily correct solution (since there's potentially a number of MCUs without 3+ SPI peripherals) but what I used to get it working:

diff --git a/libraries/SPI/src/utility/drv_spi.c b/libraries/SPI/src/utility/drv_spi.c
index 484812a..f8aee0e 100644
--- a/libraries/SPI/src/utility/drv_spi.c
+++ b/libraries/SPI/src/utility/drv_spi.c
@@ -70,10 +70,12 @@ uint32_t dev_spi_clock_source_frequency_get(spi_t *obj)
             /* clock source is APB1 */
             spi_freq = rcu_clock_freq_get(CK_APB1);
             break;
+#ifndef GD32E23x
         case SPI2:
             /* clock source is APB1 */
             spi_freq = rcu_clock_freq_get(CK_APB1);
             break;
+#endif
         default:
             //error("SPI clock source frequency get error");
             break;
@@ -114,9 +116,11 @@ void spi_begin(spi_t *obj, uint32_t speed, uint8_t mode, uint8_t endian)
     if (spiobj->spi == SPI1) {
         rcu_periph_clock_enable(RCU_SPI1);
     }
+#ifndef GD32E23x
     if (spiobj->spi == SPI2) {
         rcu_periph_clock_enable(RCU_SPI2);
     }
+#endif

     /* configure GPIO mode of SPI pins */
     pinmap_pinout(spiobj->pin_mosi, PinMap_SPI_MOSI);
@@ -201,10 +205,12 @@ void spi_free(spi_t *obj)
         spi_i2s_deinit(SPI1);
         rcu_periph_clock_disable(RCU_SPI1);
     }
+#ifndef GD32E23x    
     if (spiobj->spi == SPI2) {
         spi_i2s_deinit(SPI2);
         rcu_periph_clock_disable(RCU_SPI2);
     }
+#endif
     /* Deinit GPIO mode of SPI pins */
     pin_function(spiobj->pin_miso, SPI_PINS_FREE_MODE);
     pin_function(spiobj->pin_mosi, SPI_PINS_FREE_MODE);
djix123 commented 2 years ago

Similarly I2C works fine, but needed to add this patch so that twi.c will compile for the GD32E230. Most notably the nvic_irq_priority function only takes two parameters. The typical sub-priority is left out. [I tested versus I2C1 since the board I have has a crystal on PF0/PF1 and Serial is using PA9/PA10]

diff --git a/libraries/Wire/src/utility/twi.c b/libraries/Wire/src/utility/twi.c
index 4c2e152..2cc6926 100644
--- a/libraries/Wire/src/utility/twi.c
+++ b/libraries/Wire/src/utility/twi.c
@@ -82,7 +82,7 @@ static struct i2c_s *obj_s_buf[I2C_NUM] = {NULL};

 #define I2C_S(obj)    (struct i2c_s *) (obj)

-#if defined(GD32F1x0) || defined(GD32F3x0) || defined(GD32F4xx)
+#if defined(GD32F1x0) || defined(GD32F3x0) || defined(GD32F4xx) || defined(GD32E23x)
 #define GD32_I2C_FLAG_IS_TRANSMTR_OR_RECVR I2C_FLAG_TR
 #else
 #define GD32_I2C_FLAG_IS_TRANSMTR_OR_RECVR I2C_FLAG_TRS
@@ -154,14 +154,24 @@ void i2c_slaves_interrupt_enable(i2c_t *obj)
     switch (obj_s->i2c) {
         case I2C0:
             /* enable I2C0 interrupt */
+#ifndef GD32E23x
             nvic_irq_enable(I2C0_EV_IRQn, 1, 3);
             nvic_irq_enable(I2C0_ER_IRQn, 1, 2);
+#else
+            nvic_irq_enable(I2C0_EV_IRQn, 1);
+            nvic_irq_enable(I2C0_ER_IRQn, 1);
+#endif
             break;
         case I2C1:
             /* enable I2C1 interrupt */
+#ifndef GD32E23x
             nvic_irq_enable(I2C1_EV_IRQn, 1, 3);
             nvic_irq_enable(I2C1_ER_IRQn, 1, 2);
             break;
+#else
+            nvic_irq_enable(I2C0_EV_IRQn, 1);
+            nvic_irq_enable(I2C0_ER_IRQn, 1);
+#endif
         default:
             break;
     }
maxgerhardt commented 2 years ago

Thanks for the feedback and patches, I'll have a look at this tomorrow -- indeed the SPI code shouldn't assume which exact SPI peripherals are available, we have to clean up this technical debt inherited by GigaDevice's original code.

djix123 commented 2 years ago

Another (very) minor patch to exclude the usbd peripheral directories from the build path (since the GD32E230 doesn't have one). Again probably a better way to do this.

diff --git a/tools/platformio/platformio-build.py b/tools/platformio/platformio-build.py
index 0ac1344..30dc1af 100644
--- a/tools/platformio/platformio-build.py
+++ b/tools/platformio/platformio-build.py
@@ -229,13 +229,8 @@ env.Append(
         join(FRAMEWORK_DIR, "system", spl_series + "_firmware", "CMSIS"),
         join(FRAMEWORK_DIR, "system", spl_series + "_firmware", "CMSIS", "GD", spl_series, "Include"),
         join(FRAMEWORK_DIR, "system", spl_series + "_firmware", "CMSIS", "GD", spl_series, "Source"),
-        join(FRAMEWORK_DIR, "system", spl_series + "_firmware", "CMSIS", "GD", spl_series, "Source", "GCC"),
         join(FRAMEWORK_DIR, "system", spl_series + "_firmware", spl_series + "_standard_peripheral", "Include"),
         join(FRAMEWORK_DIR, "system", spl_series + "_firmware", spl_series + "_standard_peripheral", "Source"),
-        join(FRAMEWORK_DIR, "system", spl_series + "_firmware", spl_series + "_usbd_driver", "Include"),
-        join(FRAMEWORK_DIR, "system", spl_series + "_firmware", spl_series + "_usbd_driver", "Source"),
-        join(FRAMEWORK_DIR, "system", spl_series + "_firmware", spl_series + "_usbfs_driver", "Include"),
-        join(FRAMEWORK_DIR, "system", spl_series + "_firmware", spl_series + "_usbfs_driver", "Source"),
         join(FRAMEWORK_DIR, "cores", "arduino"),
     ],
     LINKFLAGS=[
@@ -261,6 +256,17 @@ env.Append(
 #    LIBPATH=[join(CMSIS_DIR, "DSP", "Lib", "GCC")],
 )

+if not board_config.get("build.spl_series").lower().startswith("gd32e23"):
+    env.Append(
+        CPPPATH=[
+            join(FRAMEWORK_DIR, "system", spl_series + "_firmware", "CMSIS", "GD", spl_series, "Source", "GCC"),
+            join(FRAMEWORK_DIR, "system", spl_series + "_firmware", spl_series + "_usbd_driver", "Include"),
+            join(FRAMEWORK_DIR, "system", spl_series + "_firmware", spl_series + "_usbd_driver", "Source"),
+            join(FRAMEWORK_DIR, "system", spl_series + "_firmware", spl_series + "_usbfs_driver", "Include"),
+            join(FRAMEWORK_DIR, "system", spl_series + "_firmware", spl_series + "_usbfs_driver", "Source"),
+        ],
+    )
+
 env.ProcessFlags(board_config.get("build.framework_extra_flags.arduino", ""))

 configure_application_offset(mcu, upload_protocol)
maxgerhardt commented 2 years ago

Fixes for I2C, SPI and the PlatformIO builder script were incorporated in 18c4fcc6a4588844ea88cf1ce76348be01dd15a0, f67aa96195cf494456e1885f3c1796ad2572bda9, d84dda518ec4fea5322c2687499f76f9745290f0 and 1058e0cd6a8b6bf1baaa876a1f2fe164eb3d107a.

Can you test your old sketches with this current git version, do they still work? Were there any other issues with the core or built-in libraries?

djix123 commented 2 years ago

Can confirm the fixes work for me with the GD32E230F8 board. Compiles and works as expected. The two libraries I used were: Adafruit SPIFlash for confirming the SPI functionality and Adafruit BusIO / Adafruit_BME680 to confirm the I2C functionality.

One thing I did note, though, is that the update to install gdlink-cli installs the Windows version on the Mac. Maybe better not to install anything if no Mac version is available (assuming there isn't since I couldn't find one when I last looked).

Just noticed something else, when I click the 'Upload' button in PlatformIO it re-downloads gdlink-cli even though its already installed.

maxgerhardt commented 2 years ago

Thanks for confirming the code still works.

Just noticed something else, when I click the 'Upload' button in PlatformIO it re-downloads gdlink-cli even though its already installed.

This should be counteracted through https://github.com/CommunityGD32Cores/pio-gd32-gdlinkcli/commit/7f0f48094307d9953b7506f71e480c2083ea0b77. For now, I only need thihs GDLinkCLI tool, which is provided by GigaDevice as a Windows-only tool, to upload comfortably to a GD32E50x device while my OpenOCD patch (https://review.openocd.org/c/openocd/+/6794) is not completed yet.

I will close this issue as solved for E230x then.

djix123 commented 2 years ago

Thanks - the update to gdlinkcli fixes the continual re-download.

Also just playing with the Arduino Timer example. Not working on the GD32E230 ... will try and figure out why.

maxgerhardt commented 2 years ago

cores/arduino/gd32/timer.c is missing some case statements for higher timers avialable on GD32E23x, like TIMER14, 15 and 16. PWM on pins using these timers won't work without that.

There's also a fundamental bug in getTimerUpIrq in regards to detecting which timers exist and returning the interrupt based on that, it uses a #ifdef on a enum type value... gotta fix those.

maxgerhardt commented 2 years ago

Could update again to see if https://github.com/CommunityGD32Cores/ArduinoCore-GD32/commit/8fd01efc1c758e2ef17df31eb67e04329ae070a4 fixes the issue? You should be using code like https://github.com/CommunityGD32Cores/gd32-pio-projects/blob/main/gd32-arduino-pwm-out/src/main.cpp together with a PWM enabled pin as listed in e.g. https://github.com/CommunityGD32Cores/ArduinoCore-GD32/blob/main/variants/GD32E230F8_GENERIC/PeripheralPins.c#L130-L148