Getting a GDE103CBT6 board to work

[crosswick]

Hi! This is a continuation of the discussion at https://github.com/platformio/platformio-core/issues/3927

I think the issue might be that on my board, there is actually a CB version of the E103 chip instead of a C8, as on the aliexpress link I sent you.

Could you make a board definition for this, please?

[maxgerhardt]

Added in c38e544dfb820997ea9a7974099800fbda4e700d and d5495c8ecb90e8141503b4fa8aa6c17c40863201 and blinky project updated in https://github.com/maxgerhardt/gd32-pio-projects/commit/b1e93608cbc6731eade4e949ad57c2d677ec0a3f.

With what tool are you uploading? STLink? Are there any errors / warnings appearing when uploading?

Also your board has a 8MHz crystal on it, yes? Currently system_gd32e10x.c statically selects the clock source to 8MHz HSE + PLL to 120MHz.

[maxgerhardt]

Ah, to update it you will need to remove the <home folder>/.platformio/packages/framework-spl-gd32-* and <home folder>/.platformio/platforms/gd32* folders and rebuild the project, that should trigger a redownload.

[crosswick]

With what tool are you uploading? STLink?

Yes an ST-Link V2, bootleg edition.

Also your board has a 8MHz crystal on it, yes? Currently system_gd32e10x.c statically selects the clock source to 8MHz HSE + PLL to 120MHz.

It does, yes.

Are there any errors / warnings appearing when uploading?

Yesterday with the C8 version there was yes, concerning the RAM size. Today it doesn't compile... I've downloaded the repo again, made the change to the platformio.ini file and it now says in the terminal when buiding:

> Executing task in folder gd32-spl-blinky: platformio run <

Processing genericGD32E103CB (board: genericGD32E103CB; framework: spl; platform: https://github.com/maxgerhardt/platform-gd32.git)
----------------------------------------------------------------------------------------------------------------------
Error: Unknown board ID 'genericGD32E103CB'
The terminal process "platformio 'run'" terminated with exit code: 1.

Terminal will be reused by tasks, press any key to close it.

This is my platformio.ini:

[env]
platform = https://github.com/maxgerhardt/platform-gd32.git
platform_packages = 
    framework-spl-gd32@https://github.com/maxgerhardt/pio-spl-gd32-new.git

[env:genericGD32E103CB]
board = genericGD32E103CB
framework = spl
; below is board specifc.
; when not building for GD32E103V_EVAL or GD32E103R_START,
; the SPL framework needs to know the frequency of the high-speed crystal.
; if none is used, this value can be anything.
; see gd32e10x.h lines 52 following.
build_flags = 
    -DHXTAL_VALUE=8000000U
    -DHXTAL_VALUE_8M=HXTAL_VALUE

[maxgerhardt]

Error: Unknown board ID 'genericGD32E103CB'

Then it hasn't updated / redownloaded the platform folder and still has an old version. As per above, remove all folders of the form <home folder>/.platformio/platforms/gd32* and that should go away.

[crosswick]

Ah I see, my bad for skipping over that part. It now does compile but I get a similar error when uploading as yesterday:

> Executing task in folder gd32-spl-blinky: platformio run --target upload <

Processing genericGD32E103CB (board: genericGD32E103CB; framework: spl; platform: https://github.com/maxgerhardt/platform-gd32.git)
----------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/gd32/genericGD32E103CB.html
PLATFORM: GD GD32 (1.0.0+sha.d5495c8) > Generic GD32E103CBT6
HARDWARE: GD32E103CBT6 120MHz, 32KB RAM, 128KB Flash
DEBUG: Current (stlink) On-board (stlink) External (blackmagic, jlink)
PACKAGES: 
 - framework-spl-gd32 2.10000.0+sha.465e375 
 - tool-dfuutil 1.9.200310 
 - tool-openocd 2.1100.0 (11.0) 
 - tool-stm32duino 1.0.1 
 - toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)
Warning! Cannot find a linker script for the required board! Firmware will be linked with a default linker script!
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 0 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Checking size .pio/build/genericGD32E103CB/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   0.1% (used 36 bytes from 32768 bytes)
Flash: [          ]   0.7% (used 872 bytes from 131072 bytes)
Configuring upload protocol...
AVAILABLE: blackmagic, jlink, mbed, stlink
CURRENT: upload_protocol = stlink
Uploading .pio/build/genericGD32E103CB/firmware.elf
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.11.0-00155-ge392e485e (2021-03-15-18:44)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
debug_level: 1

hla_swd
0
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08000294 msp: 0x2000c000
** Programming Started **
Warn : STM32 flash size failed, probe inaccurate - assuming 128k flash
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked
============================================ [SUCCESS] Took 1.07 seconds ============================================

Terminal will be reused by tasks, press any key to close it.

[maxgerhardt]

Warn : STM32 flash size failed, probe inaccurate - assuming 128k flash

I did have that too but it ran without problems -- it's just that OpenOCD doesn't have any GD32 specific scripts yet so the closest thing I got was the STM32F1x script.

I guess there's still no blinky on PC13?

Can you go the debug sidebar and press debug? Does it start in the Reset_Handler and then reach main()? Or is it never reaching main(), in which case you can press the pause button and see where it is?

[crosswick]

No blinky indeed. I'm having some trouble getting the debugging to work, haven't done that before in platformio or VS Code... it seems to be asking for some configurations that I'm not sure of

[crosswick]

Did I perhaps delete too much from my platformio.ini?

[maxgerhardt]

Hm sometimes a VSCode restart will solve that (https://github.com/platformio/platformio-vscode-ide/issues/2554).

No your platformio.ini is fine.

Otherwise you may have conflicting VSCode extensions installed that also want to override the debugger configuration (e.g., Google Cloud..). If you have the "PIO Debug (\<project name>)" debug configuration selected per screenshot, it should start up.

[crosswick]

I don't have any other VSCode extensions installed.

I've restarted VSCode, deleted my launch.json and when I press Run and Debug, these are my options:

[maxgerhardt]

o_O That is not normal. Do you have access to the project environment switcher to select the project?

You may also try to delete the (hidden) .vscode folder of the project and restart VSCode, in hopes it will get re-generated.

Does the regenertated launch.json look like picture related?

[crosswick]

Alright please excuse my VSCode n00bness - I did now select the project in the switcher and was able to start the debugger.

It stopped automatically in Reset_Handler, so I pressed pause, this is where it is:

[crosswick]

By the way, I've just seen/remembered that I do also have the GD32E103C8 version of the board. Also F150C8, F330C8 and E230C8

[maxgerhardt]

:/ In the left debugger panel, there is a "Call stack". Does it show where it was before HardFault_Handler()?

If not, stop debugging, add

debug_init_break =

to the platformio.ini to disable automatic contination after Reset_Handler(), wait a bit (configuration reload) and restart debugging. Now you should be launched into Reset_Handler() and can manually use the "Step Into (F11)" to execute each instruction.

After debugging starts, set a breakpoint at the bl SystemInit line and press the play button (to continue). Does it hit the breakpoint then? When you "Step Into" then, does it reach the SystemInit() function? Is it able to execute that function all the way to the end without crashing?

[crosswick]

:/ In the left debugger panel, there is a "Call stack". Does it show where it was before HardFault_Handler()?

I'm not sure, does it?

[crosswick]

After debugging starts, set a breakpoint at the bl SystemInit line and press the play button (to continue). Does it hit the breakpoint then?

It does, yes

When you "Step Into" then, does it reach the SystemInit() function? Is it able to execute that function all the way to the end without crashing?

doesn't seem so, no:

[maxgerhardt]

Are you 100% sure the chips says GD32E103CB on it? If it cannot get into the SystemInit() function it usually indicates that the stack pointer setup is broken because the linker script thinks the chip you're compiling for has more RAM than it actually has.

If the SP setup is good then pressing this (and assuming the current execution is halted as bl SystemInit)

should get you there

Also, please start debugging again, go to the "Debug Console" tab while the chip is paused (pause button) and execute the command

x/1x 0x1FFFF7E0

it should show something like

0x1ffff7e0: 0x00300100

please post the number that you get.

[crosswick]

Are you 100% sure the chips says GD32E103CB on it?

Sigh.. I'm not. It must be a C8 after all, that would make sense. In my defense it does look a lot like a B, and together with the earlier flash size warning...

[maxgerhardt]

Looks like B chip marking to me though. In any case, reading out 0x1FFFF7E0 will show the truth.

[crosswick]

0x1ffff7e0: 0x00200080

[crosswick]

must be C8 right

[maxgerhardt]

From http://www.gd32mcu.com/data/documents/yingyongbiji/GD32E10x_User_Manual_Rev1.5.pdf

So 0x00200080 means 0x0020 SRAM = 32 (KB) and 0x0080 Flash = 128 KB. So it is a CB (https://www.gigadevice.com/microcontroller/gd32e103cbt6/ vs https://www.gigadevice.com/microcontroller/gd32e103c8t6/).

Let me look for other problem sources.

[crosswick]

Ha, what a rollercoaster :)

I've just tried the same with my other E103 board: 0x1ffff7e0: 0x00140040

[crosswick]

this does look like a real C8:

I've switched to that definition (copied its definition into the .ini first) and compiled/uploaded but no blinky yet

[maxgerhardt]

I've just tried the same with my other E103 board: 0x1ffff7e0: 0x00140040

Yes that's the 20KByte RAM 64KByte flash one, so the C8 version, that looks okay.

[crosswick]

Alright - the C8 doesn't reach the SystemInit() function either in debugging

[maxgerhardt]

Can you restart the debugging with the breakpoint at bl SystemInfo, let it hit that breakpoint, and then go to the Debug console and execute stepi (step instruction)? What happens then in the output log and code location? Goes directly into Hardfault Handler?

[crosswick]

do you mean bl SystemInit? assuming you do:

79      bl  SystemInit
stepi
{"token":19,"outOfBandRecord":[],"resultRecords":{"resultClass":"running","results":[]}}
Info : halted: PC: 0x080003c0
halted: PC: 0x080003c0
SystemInit () at /Users/theadmin/.platformio/packages/framework-spl-gd32/gd32/cmsis/variants/gd32e10x/system_gd32e10x.c:109
109 {

[maxgerhardt]

SystemInit () at /Users/theadmin/.platformio/packages/framework-spl-gd32/gd32/cmsis/variants/gd32e10x/system_gd32e10x.c:109 109 {

Oh that looks like it actually went into the function though. Can you execute stepi again and then go "Switch to Code"?

[crosswick]

Ah yes it did get into the SystemInit function; pressing Step Into a couple of times does end up in the HardFault_Handler

[maxgerhardt]

Oh that's interesting. Can you determine at which exact line of code or instruction that is by single-stepping in either the code or assembly view?

[crosswick]

How do I single-step?

[maxgerhardt]

With "Step-Into (F11)" in the debugger toolbar shown above -- single step just means executing each code line step-by-step.

[crosswick]

Ah I see. First it reaches line 116; after that it's HardFault time

[maxgerhardt]

Does it make a difference when you comment the line

    SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2));  /* set CP10 and CP11 Full Access */

and retry?

Does it make a difference when you comment the line

#define __SYSTEM_CLOCK_120M_PLL_HXTAL           (uint32_t)(120000000)

and uncomment

//#define __SYSTEM_CLOCK_120M_PLL_IRC8M           (uint32_t)(120000000)

(all in system_gd32e10x.c)?

Also when execution reaches the Hardfault Handler, can you execute

p/a *(uint32_t[8] *)$psp

in the debug console and post the output?

This is really interesting :/. I may have another approach to this (different linker script) though too.

[crosswick]

Sorry, where do I find system_gd32e10x.c ? searching for 'scb' for instance in the gd32-spl-blinky folder doesn't give any results, and I can't find the file by browsing in the tree

[maxgerhardt]

When you start debugging and the execution flow goes into SystemInit(), that's the file. It should also be in <home folder>/.platformio/packages/framework-spl-gd32/gd32/cmsis/variants/gd32e10x/system_gd32e10x.c, you can drag&drop the file into VSCode.

[crosswick]

Does it make a difference when you comment the line SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); /* set CP10 and CP11 Full Access */ and retry?

nope

[crosswick]

Does it make a difference when you comment the line

#define __SYSTEM_CLOCK_120M_PLL_HXTAL (uint32_t)(120000000) and uncomment

//#define __SYSTEM_CLOCK_120M_PLL_IRC8M (uint32_t)(120000000)

nope

[crosswick]

Also when execution reaches the Hardfault Handler, can you execute p/a *(uint32_t[8] *)$psp in the debug console and post the output?

$1 = {0x0
7
, 0x0
}

[crosswick]

or perhaps also this

[maxgerhardt]

Hm the (7) probably means it has hidden 7 elements of the same value. Just out of curousity, does it output the same when you replace psp with msp in the command? (While execution is paused in the Reset_Handler() of course.

Also, this is pure magic. I can compile, upload and execute the firmware compiled for a GD32E103CB board on my GD32F303CC board and it runs just fine, seems to be register compatible. I don't yet know why it crashes so early for you.

Can you again place a breakpoint at the entry of the SystemInit() function as so

then start debugging and press continue until you hit that breakpoint.

Then press "switch to assembly"

And keep pressing "Step Into (F11)" until it suddenly jumps into HardFault_Handler. Can you show a screenshot of line that it's at before jumping into HardFault?

[crosswick]

Hm the (7) probably means it has hidden 7 elements of the same value. Just out of curousity, does it output the same when you replace psp with msp in the command? (While execution is paused in the Reset_Handler() of course.

[crosswick]

Can you show a screenshot of line that it's at before jumping into HardFault?

[maxgerhardt]

Can you let execution run to that exact point again shown in your screenshot above and execute in the debug console the commands

i r sp lr
x/1x $pc+64

also you are running this on the C8 board with the C8 environment selected in the project environment switcher, yes?

[crosswick]

also you are running this on the C8 board with the C8 environment selected in the project environment switcher, yes?

yes

[maxgerhardt]

Okay, the error is exactly there. The stack pointer has the wrong value. SP being 0x2000bff8 after having pushed two 32-bit registers means the original valuel was 0x200c000 and with SRAM starting at 0x20000000 and the SP being initialized at the end of SRAM, it means the linker thinks your board has 0xc000 bytes of SRAM, which is 48 Kilobytes. The GD32E103C8T6 only has 20 Kilobytes and thus will crash when accessing RAM that isn't there. It's as if the GD32F303CC board was still selected.

The question is how that value can get there. Because the RAM amount definition is correct

https://github.com/maxgerhardt/platform-gd32/blob/6ba430bfe459a1f133a688946cfa789a1c867870/boards/genericGD32E103C8.json#L30-L32

Your platformio.ini should look like

[env]
platform = https://github.com/maxgerhardt/platform-gd32.git
platform_packages = 
    framework-spl-gd32@https://github.com/maxgerhardt/pio-spl-gd32-new.git

[env:genericGD32E103C8]
board = genericGD32E103C8
framework = spl
build_flags = 
    -DHXTAL_VALUE=8000000U
    -DHXTAL_VALUE_8M=HXTAL_VALUE

in the gd32-spl-blinky project folder. Can you tripple check / overwrite it to that please, then re-upload the project?

If it is still not working, try doing https://github.com/maxgerhardt/platform-gd32/issues/1#issuecomment-865850088 again to trigger a fresh redownload.

As long as that value of SP at that point is not 0x20004ff8, something is wrong.

[crosswick]

It looks exacty the same, yes... perhaps you can quadruplecheck :)

[maxgerhardt]

This looks good. Can you show a screenshot of the whole VSCode window?

When you build the firmware normally in PlatformIO using the build button in the bottom toolbar, you should be getting

RAM:   [          ]   0.2% (used 36 bytes from 20480 bytes)
Flash: [          ]   1.3% (used 824 bytes from 65536 bytes)
Building .pio\build\genericGD32E103C8\firmware.bin
========= [SUCCESS] Took 2.72 seconds =========

right?

Have you redownloaded the platform & framework yet by deleting the old folders?

[crosswick]

Sigh... I'm sorry. Only now I'm reading that #1 comment correctly, and have correctly deleted the necessary folders.

Both C8 and CB are blinking.

I apologize for the error and the wild goose chase.