false

false

中文

GR551x SDK demos won't work with GCC and/or GR5515I0ND

die****com

2021-11-23 02:38:11

In the GR551x SDK 1.6.10 Release notes it mentions that "The GCC has not been fully tested. If there are any problems in actual use, please give us feedback for troubleshooting", which I presume this is the channel for that.

After leaving one board unusable with the "projects\peripheral\qspi\qspi_flash" demo, thinking that I made the mistake of enabling the  EXT_EXFLASH_ENABLE flag in custom config, I set myself decided to not make the same mistake again and try with a different non-related demo on my second board, so I decided to go with a simple BLE demo, which should be common enough to any possible GR551x configuration. For that I chose the "projects\ble\ble_basic_example\ble_app_gatt_server", which sounded basic enough to not do much harm... So after building and flashing and some attempts of debugging, I ended up with a second board in the exact same state as the first one, without the  EXT_EXFLASH_ENABLE flag enabled this time, which makes me presume that it's not related to that then. So now, GProgrammer first won't detect any firmwares in my device, and second will refuse to write on the flash memory.. So I'll document the exact steps that I followed with the hopes that somebody will help me understand what am I doing wrong, or if it's just that the GCC stack simply doesn't work at the moment, or maybe the demos are just not compatible with the GR5515I0ND SOC. I honestly don't know.

0. Go to the project folder "projects\ble\ble_basic_example\ble_app_gatt_server "

1. Copy "keil2makefile.py" into the "keil_5" folder.

2. Run the command "python keil2makefile.py ble_app_gatt_server.uvprojx" in order to generate the "make_gcc" folder.

3. I decide where in the flash I want to store the firmware: 0x01045000

4. Modify the file "Src/config/custom_config.h", with the following changes:

4.1. Change the value of "SK_GUI_ENABLE" to 0, since I won't be needing it (I've tried also with it set to 1, with no change)

4.2. Change "APP_CODE_LOAD_ADDR" to 0x01045000.

4.3. Change "APP_CODE_RUN_ADDR " to 0x01045000, to indicate that the firmware will run in XIP mode.

5. Copy the file "gcc_linker_gr5515_d.lds" into the "make_gcc" folder, since I'm going to modify the flash section to reflect the firmware address (I also copy the "rom_symbol_gcc.txt" and "startup_gr55xx.s" files in case I need to change them in the future, but I haven't touched them so far):

5.1. Comment the original MEMORY section, to keep it for future reference.

5.2. Copy the old MEMORY section and change the FLASH entry to: "FLASH (rx) : ORIGIN = 0x01045000, LENGTH = (0x00800000 -0x00045000)"

6. In "make_gcc" folder, edit the makefile, and perform the following changes:

6.1. Since I'm in windows, comment the " du -h $@" line, as instructed in the guide.

6.2. Change "LINK_SCRIPT", "PATCH_FILE" and "GCC_STARTUP_ASM_FILE" to make them point to my local files.

7. Build the project by running "make". The build is successful.

8. Open GProgrammer, go to the firmware section and click the "Add" button to add a new firmware.

9. Select the newly created bin file. Click the "Startup" button to make it the startup firmware, and click the "Commit" button. Then  GProgrammer disconnects, and all seems fine, upon reconnection it displays my firmwares.

10. Now I attempt to debug with GDB and "J-Link GDB Server V7.00". For that I'll use VSCode with the "Cortex-Debug" extension, which is basically only using GDB under the hood, no fancy stuff.

11. I create a launch.json file, with one "cortex-debug" task for "launch", and one for "attach", although I'll use the attach one. I configure it to use "jlink" over "swd" for a "Cortex-M4" device, and the generated " ble_app_gatt_server.axf " as executable. Finally I add some postAttach commands to try to emulate the "sram.ini" file that you provide for Keil. In this commands is where I have tried most combinations that I can imagine, but the ones that I've used for this project are the following:

"monitor endian little",

"monitor speed 1000",

"monitor reset",

"monitor sleep 100",

"monitor speed 2000",

"monitor writeu32 0xE000ED08 = 0x00000000",

"load ",

// I've also tried setting SP and PC at this point, but the bootloader should know how to load the firmware

"break main",

12. I set a breakpoint at the beginning of "main" in "main.c" in vscode, and start the debug task.

13. The debugger stops (or seems to stop) in the "SystemInit" line of the "Reset_Handler" defined in "startup_gr55xx.s". I hit continue hoping that it will reach the endpoint in main, but it never does.

14. Try to debug again. But this time when it stops in SystemInit, I try to print the lines from $pc, and I realise that it's all zeros. So I try to read the flash memory locations for  0x01045000 onwards in J-Link commander, but it displays all zeros. Same for 0x01000000.

15. I open GProgrammer again and upon checking the " SPI Access Mode" of my firmware I notice that it's value is EB. So I change it in the "Info Data" section of the dfu bin file to 03, which is the only mode that I know it works, in a binary file editor, and try to re-flash (if there is a list documenting what's the meaning of each value I've missed it, but it's definitely not in the developer guide or the dfu application note, and if it's in the datasheet is under a different name). It seems to flash correctly, since it still recognises the firmware upon reconnection.

16. I try to debug again with same results as earlier. Memory still all zeroes for the flash area. ROM, RAM, etc seem fine

17. I go back to Gprogrammer and check all the other areas to see if there is anything wrong. All seems ok, so I try to debug again manually setting PC this time to where the firmware is .

178. At some random point with no changes but still trying to debug, when trying to connect to GProgrammer, it won't recognise any firmwares in my flash, and won't allow to write

-----------------

At this point I should not lose any more boards, so I'll stop and see if we can find a solution for developing with GCC.

For my environment, I followed the instructions from the GCC user manual to the point, even if the versions were not the latest ones. My environment is:

SOC: GR5515I0ND

OS: Windows 10 Pro - Version 10.0.19043 Build 19043

MSYS:  MSYS-1.0.11

GCC Stack:  gcc-arm-none-eabi-9-2020-q2-update-win32


P.S.: Sorry for the long post. I hope I didn't miss any points since I wrote this post few hours after loosing the board and trying to figure out what's going on. A more thorough GCC manual would be highly appreciated, since at the moment it barely touches the topic superficially in terms of configuration and operation. In particular, a section on debugging is definitely missing.

Hot Latest

11 Answers

freeman

2021-11-23 10:58:28

hi 

We are checking whether the 1.6.10 SDK supports GCC synchronously. We will tell you the results later. Before that, can you make an attempt to burn the demo firmware preset by our SDK onto your board and observe whether it works normally.

1、You can also tell us your hardware settings. We will send you a firmware according to these settings, such as GPIO for serial port.

2、Can u send me the bin file you created , it would be better if the map file could be attached.

thank you

0 Comments

Your comment

freeman

2021-11-25 11:07:23

hi

1、i have tried your bin, it is good to run, so your sw-env is ok.

2、i check your operation about GProgrammer , it looks like some error happens after start your app fw. but i can sure it is not enter sleep state if you use this  ble_app_template demo.

3、when you click startup button, the tools will write the boot info into flash. So now it looks like the firmware has been downloaded into FLASH correctly, so the tool side is fine?

4、 According to your description, I think you can try the following, download the firmware to your board through the tool, and click startup button, then connect through the JLINK Commander tool at this time, and try to halt the CPU, then you can send us the screenshots of the core register information.

5、I don't have this Flash<XT25F64BWOIG> chip yet, but I am contacting the supplier to send samples for testing.


thank you!


0 Comments

Your comment

die****com

2021-11-23 19:09:52

Thank you Freeman, I'll be looking forward hearing the results.

Is "ble_app_template_dfu" the firmware demo that you mention? At the moment I can't flash anything anymore, since GProgrammer refuses to write on flash (except for erasing it seems..) but I can try downloading it directly into RAM, and forcing PC into that position if that will help.

1. The board that I've been given is a GR551I0ND SOC paired with an XT25F64BWOIG external flash as per recommendation in the "GR5515I0ND Flash Selection Guide". A Bluetooth antenna connected to RFIO, and it all is powered by a 3.7V battery. At the moment none of the GPIOs are connected since currently the interest is focused on BLE operation. Later on a touch screen will be attached. I'm connecting to the SOC through SWD.

2. I sure can, which address should I send it to?

0 Comments

Your comment

freeman

2021-11-24 10:23:42

hi :


1、I have try the original SDK with GCC-env,  the bin download and run is good. i chose this one:projects\ble\ble_peripheral\ble_app_template

but i use MINGW64 lise this:

the only changes follow:

(1)、custom_config.h

#define APP_CODE_LOAD_ADDR      0x01045000
#define APP_CODE_RUN_ADDR       0x01045000

(2)、\toolchain\gr551x\source\gcc\gcc_linker_gr5515_d.lds

FLASH (rx) : ORIGIN = 0x01045000

(3)、Makefile

$(BLE_TOOL_BIN) --cfg=../Src/config/custom_config.h --mode=gen --bin=$(BUILD)/$(MAKE_TARGET_NAME).bin --outdir=$(BUILD) --app_name=$(MAKE_TARGET_APP)


2、you can send the bin file and map file to my email: zounan@goodix.com ,

thankyou!

0 Comments

Your comment

die****com

2021-11-24 17:57:57

Thank you for your test,

I've built the same demo that you mention with my toolchain (gcc + msys), with the modifications that you mention, and it's already obvious that the build is different just by checking the size:


The only difference is that in my lds file I also modified the length, since leaving it like "FLASH (rx) : ORIGIN = 0x01045000" was triggering errors, so I left it like "FLASH (rx) : ORIGIN = 0x01045000, LENGTH = (0x00800000 -0x00045000)". Is that an invalid modification?

Should we then be using mingw64 instead of msys? Which version of mingw64 are you using? And with which options did you install it?

I'll send you the bin produced by my toolchain to the specified address, and will try building with mingw64 as soon as you tell me what version should I use.

0 Comments

Your comment

die****com

2021-11-24 18:27:28

I have also built the binary with  MINGW64 and my binary is still larger than yours:


Which version of the "GNU Arm Embedded Toolchain" are you using? I'm using the one recommended on the GCC manual "gcc-arm-none-eabi-9-2020-q2-update-win32.zip".

Are you applying any extra optimisation options in your makefile?

0 Comments

Your comment

freeman

2021-11-24 19:53:02

hi :

my toolchain version like this, but ,i think your toolchain is fine too, so i can try your bin , if it is good to run, so your sw-env is good. and the next action is found the difference of HW.  






0 Comments

Your comment

die****com

2021-11-24 20:39:44

Hi,

I have put my binary of "ble_app_template" in a new board, and right after flashing, and trying to reconnect to GProgrammer, now GProgrammer is failing for that board as well. It won''t detect any firmwares and won't allow me to write to flash anymore. I can't see any bluetooth services either, so I presume that the firmware is not running. I've sent you my binary to see if you can find any issues with it.

Is there something special that I need to put into NVDS to make it work?


If I connect to the board through J-Link Commander, PC register seems to be stuck at 0x000000144

I've noticed that if I disconnect the battery and reconnect it again, sometimes GProgrammer recognises the flash memory again.


* I've dumped the boot section from flash and it seems to be ok and pointing to the right place. But the firmware doesn't seem to run

* I've tried erasing the entire flash before flashing the "ble_app_template" firmware, and reverting NVDS section to default values in GProgrammer, just in case any other existing firmwares could be messing with the flash write operation. Then once erased, I've disconnected and connected again to GProgrammer. Flashed "ble_app_template". Commit. Disconnect and reconnect. And the minute that I set " ble_app_template" as startup project and commit, the GProgrammer starts not being able to write to flash or recognise any firmwares in it. I'll try downgrading my arm toolchain to version 7.3.1 same as you have and see if that helps in any way... 

* After downgrading my gcc to version 7.3.1, I've managed to get the same binary size as yours. But still after disconnecting and reconnecting the battery to revert the flash memory back to a readable/writable state (I'm afraid that I might be damaging the board), and erasing the flash. I flashed and commited the new, smaller version of the  "ble_app_template" firmware with Gprogrammer. Disconnect and reconnect to GProgrammer to make sure that it's all ok, and it is, but after selecting the "ble_app_template" firmware, clicking the "Startup" button, and clicking the "Commit" button, GProgrammer automatically disconnects, and when I try to reconnect, it's unable to work with the flash once again.. So it seems like using the "Startup" option is what breaks the flash Are we supposed to use the "startup" button with demo firmwares? As far as I know that's what writes the boot section to make the bootloader boot that firmware, correct?


* One more (final?) experiment. After disconnecting and reconnecting the battery, I've dumped the flash and it seems like the initial segment of the "boot info" area of the flash went back to all 0s. So what I did is manually write the boot information in a binary file editor, over a previous dump of the flash, and download the entire dump. So basically I manually emulated what I presume the "Startup" button does, but without using the startup button. It flashes correctly, and I dump the entire flash again just to check that everything was written correctly. At this point GProgrammer can still connect and disconnect. After that I connect with J-Link commander and reset the SOC (which I presume is what the "Commit" button does), and right after that GProgrammer once again cannot work with my flash. So it seems that running the SDK demo firmwares somehow disables my flash, or at least makes GProgrammer unable to work with it anymore. Could it be that the system enters a permanent sleep state after running the firmware? I can connect to the SOC through J-Link Commander, it's just the flash what seems to be gone. My best guess is that they are doing some sort of flash initialisation that is not compatible with XT25F64BWOIG flash module for GR5515I0GND

0 Comments

Your comment

die****com

2021-11-25 18:23:53

Hi,

That is correct. Firmware seems to download correctly every time, I can connect and disconnect from GProgrammer, and it will always be able to recognise my firmware after flashing as long as I don't click the "Startup" button on that firmware. The problem comes when I click on the "Startup" button on one of the SDK demos. That's why I think that the firmware initialisation must be doing something that is not compatible with the "XT25F64BWOIG" flash unit. I've tried tweaking the "EXFLASH_WAKEUP_DELAY" to adjust the tRes1 value, but the result is always the same. The status of my registers is the following (it changes if you halt at different times): 


Please let me know when you manage to test with the "XT25F64BWOIG" module.

Thank you very much for your time

5 Comments

Your comment

freeman

2021-11-26 10:05:19

hi

according to your screenshot of core register, i can see ,the boot process of rom is fail, beacuse the PC point to ROM space , and 0x6F6BC is ROM DFU process program.

so could u read these registers via jlink commander: 

(1)、mem32  0xA000C578 1 

(2)、mem32  0x00800040 1


thank you!

0 Comments

Your comment

11 Records
1 2 >

Your Answer