false

false

中文

Undocumented registers in the GR551x SDK 【Resolved】

die****com

2021-11-17 01:33:36

Browsing through different parts of the SDK documents I can see references to different registers which don't seem to be documented in the SDK. Some of them are ARM registers like 0xE000ED88, but some others seem to be Goodix-specific registers which I can't find any information about in the 388 pages long datasheet; more prominently the 0xA000C578, which seems to be related to a warm boot process or security debug and is used in firmware boot examples. Is there any place where we can see the information about those registers like what's the meaning of each bit-field? Thank you in advance

Hot Latest

4 Answers
The Best Answer

{-}{-}

2021-11-19 16:54:27

Hi,

Thanks for your excellent questions!

1. About 0xA00c578,

0xA000C578 is one debug purpose register which is used to record the app address for boot loader, there are two cases:

1. if its value is zero, the default value, then bootloader will check boot_info sector to look for app address for boot jump

2. if the value is an valid code address, like flash or ram space, then boot loader will jump to that address, which is the code snippet you saw in the sram.ini, we used to change it in ram code debug mode, for example, when you compiled your code load / run address in ram space, and download by keil jlink mode into ram, then you need to change the 0xA000C578 with your APP first address to tell boot loader where your code is located, otherwise, boot doesn't know where to jump.notes: when used for ram code address, the last 10bits must be all zeros, which means app code address should be placed at 1KB boundary alligned.we also record the boot path in the register by few bits, which for pure debug purpose.

//bit usage for SOFTWARE_REG 0xA000C578

//bit[3:0] ~ XFlash setup time

//--bit[2:0]: T_setup

//--bit[3]: unit indicator, 0 ~ ms, 1 ~ us

//------if bit[3] = 1, then T_setup = 2^(num + 3) (us), range from 0us to 1024us

//------if bit[3] = 0, then T_setup = num (ms), range from 0ms to 7ms

//bit[7:4] ~ Boot path

//bit[8] ~ wakeup flag

//bit[9] ~ flash copy flag

//bit[31:10] ~ ram code address

#define SOFTWARE_REG_DATA (*((volatile uint32_t*)(0XA000C578UL)))


2. About the plan to support full GCC stack, I think we need sometime, and we have gather a group to make up, up to now, I can not make sure the update time, but when the schedule is sure, I will tell you immediately.


If any problem, please tell us, thanks.

Kellan.

Best Regards.


0 Comments

Your comment

{-}{-}

2021-11-18 13:38:32

Hi,

The 0xA00C578 register is used for PMU relative, up to now, we didn't open it for customer, is there any problem that you meet? we can provide the material based on questions, thanks.


If any problem, please tell us, thanks.

Kellan

Best Regards.

0 Comments

Your comment

die****com

2021-11-19 01:50:03

Hi Kellan, thank you for your answer,

I'm trying to setup a debug environment using command line GDB, which I'm honestly struggling with, and while trying to figure out the parameters necessary for JLink, I came across "sram.ini" which states a reference to such register  0xA00C578 (even though that register is commented, the comment picked my attention). So I was basically trying to understand what's going on inside that file to try replicate it using GDB, which I'm really surprised is not covered on the GCC guide, since it's not a straightforward process setting up debugging. Are there any plans on supporting the full GCC stack anytime soon?

0 Comments

Your comment

die****com

2021-11-19 17:39:37

Thank you very much Kellan, you're being incredibly helpful.


Thank you for explaining its behaviour, it's really handy to have such functionality. At the moment I'm running everything in XIP mode so it seems I won't be needing it, but at least now I know why I don't need it and when should I use it :).


Kind regards

0 Comments

Your comment

4 Records
1

Your Answer