Hi, All
Could you help me, how can i create project with custom MCU, outside of the platform list?
BR
Anton G.
Hi, All
Could you help me, how can i create project with custom MCU, outside of the platform list?
BR
Anton G.
That very heavily dependes on what that “custom MCU” is and if there’s already a platform
to support it. Is it an STM32 chip, or what?
No, GOODIX platform.
It is CM4.
I think, that i should use CMSIS framework ?
May be, examples exist for any non-listed MCU ?
I’m too lazy to write the documentation
I guess you’re talking about some Goodix Bluetooth chip that has a Cortex-M4F? Exact chip name still unknown.
You need know quite a bit about PlatformIO to be able to create your own platform, framework builder, board definition, etc. I’d recommend reading through
Thanks.
You are right , GR551X with BLE
So, it is not a trivial way.
Have i understood well ? - framework builder is the .py script, that download SDK/framework from platformIO git?
No, the PlatformIO core already downloads the SDK or framework files package in accordance to what the platform declares in its platform.json
file (other example). The packages can refernece the PIO Registry version, or a directly Git or HTTPS downlink as their source, but the download target must always contain a package.json
metadatafile (see previous links.).
The framework builder script is a .py script that sets up the build settings (compiler flags, to be built .c, .cpp, .S files, include paths, what linker script to use, linker settings, etc.), using mostly SCons commands. For example, cmsis.py.
For your platform you’ll at least need.
I can setup a base platform for the GR551X to show what I mean.
So I could use own git repository with GOODIX SDK / CMSIS and pio_core will pull it automatically with using platform.py ?
Many thanks for this.
Because I am confused in searching entry point of implementation.
Should I change .py scripts ? Or i can configurate only json files ?
I’m currently working on it. But what I can already say is that using purely CMSIS will be hard – they don’t offer a pure CMSIS framework, their startup and system files are heavily interlinked with the SDK so that you can basically not use it without them. This would require some work to pull them apart. Regular SDK examples should be more doable.
Edit: Some work in progress
I’ve put in quite some work in the platform and it’s now able to build SDK applications, even BLE ones.
Can you test that out?
First, create a new blank project (e.g. for the Arduino Uno + framework = Arduino). Then, open a PlatformIO core CLI. Execute
pio pkg install -g -p https://github.com/maxgerhardt/platform-goodixgr.git
Then copy paste all files (platformio.ini
, src/*
) from https://github.com/maxgerhardt/platform-goodixgr/tree/main/examples/sdk-blink into the project and press build. It should generate a .pio/build/genericGR5515IGND/firmware.bin
. Can you flash that with the GProgrammer software and check the output?
Good day
I dont know, how i can thanks you for your work and help .
Great thanks.
I’ll check it out on my HW today and write here about results.
BR
Anton G.
Sorry, could you add SDK 1.7.0 ?
I can test all goodix system components on my old project.
Does the provided sdk-blink
application not work? The SDK 1.x may have a different folder structure or build requirements, so it might need some non-trivial adaptations. This 2.x SDK that is integrated now should still work and output something.
yes, I try to implement it. And have built sucessfully.
Unfortunatly, I have burned my jlink recently and wait for delivery of new soon. So for now i use goodix dfu and some “remote debug” with my friend
PS Ok. I guess I will wait jlink - best way.
Good Day, Maximilian
I have checked application building and flash it with Gprogrammer.
Successfull.
Only one thing with load fw before debug
J-Link>loadbin .pio\build\genericGR5515IGND\firmware.bin, 0x08000000
'loadbin': Performing implicit reset & halt of MCU.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
Downloading file [.pio\build\genericGR5515IGND\firmware.bin]...
Writing target memory failed.
I guess it happens due wrong address ( 0x08000000) for flashing
If i write fw though the GProg - I can debug FW.
BR
Anton G.
Yes, the platform is not yet integrated with the gprogrammer. Their Makefile
references a non-working
programer -t fw -p burn -i $(BUILD)/$(MAKE_TARGET_NAME).bin
command. (programmer
binary does not exist). So I’m kind of a bit stumped on how to upload it using the CLI tools and not the GUI.
There is the GR5xxx_console.exe
binary in the GProgrammer program folder, that looks like it may work.
So, can you test that manually in a PIO Core CLI, to see what command works?
<full path to GR5xxx_console.exe> load .pio/build/genericGR5515IGND/firmware.bin sector y
If that doesn’t work try it with the .elf
, or the .hex
file. (The .hex
file will only be generated after you pull the platform update, via e.g. pio pkg update -g -p https://github.com/maxgerhardt/platform-goodixgr.git
and clean + build again)
Or also
<full path to GR5xxx_console.exe> program .pio/build/genericGR5515IGND/firmware.bin y "0x01000000" 1024 0
Hi ,Maximilian
The true way of using GR_console is next :
PS E:\workspaces\pio\test> D:\Goodix\GProgrammer\GR5xxx_console.exe eraseall 0
eraseall success.
PS E:\workspaces\pio\test> D:\Goodix\GProgrammer\GR5xxx_console.exe generate ".pio/build/genericGR5515IGND/firmware.bin" ".pio/build/genericGR5515IGND/firmware_image.bin" "0x01002000" 1024 0
generate success.
PS E:\workspaces\pio\test> D:\Goodix\GProgrammer\GR5xxx_console.exe program .pio/build/genericGR5515IGND/firmware_image.bin y "0x01000000" 1024 0
0%
1%
1%
2%
3%
....
And new application is loaded and works.
I have tested it with RTT .
I have included RTT in gr551x_sdk.py
os.path.join(FRAMEWORK_DIR, "external", "segger_rtt"),
PS It is also not clear for me why Faddress during program without boot_offset. I will ask this on goodix community.
Hi
Update
load .pio/build/genericGR5515IGND/firmware.bin sector y
reset 0
also work
If you do an eraseall 0
, does it also erase the bootloader, so that after flashing the firmware at 0x01002000
again it will not execute anymore?