Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

SDK fixes for BL702 (EFUSE, USB, ADC, etc.) #145

Open
wants to merge 18 commits into
base: master
Choose a base branch
from
Open

SDK fixes for BL702 (EFUSE, USB, ADC, etc.) #145

Changes from 1 commit
Commits
Show all changes
18 commits
Select commit Hold shift + click to select a range
b6199b2
Fix CLIC register sizes
May 13, 2023
ae8f6e5
Add callback for low-level initialization before SystemInit
May 13, 2023
53c0ef8
Add required functions to get current clock settings
May 13, 2023
fe0e015
Fix compilation warning
May 13, 2023
b0fd101
Use GLB_Set_System_CLK_Div ROM implementation if BFLB_USE_ROM_DRIVER …
May 13, 2023
4d8363c
Fix compilation warnings
May 13, 2023
46f5981
Fix EFUSE API functions to use proper EFUSE value addresses and
May 13, 2023
e559bfd
Fix invalid double inclusion definition macro
May 13, 2023
95e5934
Implement proper I2C bus NAK condition handling for unresponsive devices
May 13, 2023
1dfb247
Add missing ADC clock divider definition
May 13, 2023
725478b
Fix bflb_adc_channel_config() function prototype and correct maximum …
May 13, 2023
153ba83
Fix compilation warnings
May 13, 2023
c03f725
Massive reworks of EP0 control transactions handling to improve stabi…
May 13, 2023
597077a
Add support for GET_REPORT HID requests with lengths greater than 1 b…
May 13, 2023
fc313fe
Fix for GPIO9...GPI13 and GPIO23...GPI28 parameters initialization: p…
May 17, 2023
d6c2771
Corrected cycle ranges to get all CLIC registers initialized.
May 26, 2023
638ded6
Restricted GLB_GPIO_USE_PSRAM__IO_OFFSET_ADDR processing only for BL7…
May 26, 2023
ba2efc7
Fix using register value instead of it's address.
May 29, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions drivers/soc/bl702/std/startup/system_bl702.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,7 @@

void SystemInit(void)
{
uint32_t *p;
uint8_t *p;
uint8_t i;
uint32_t tmpVal = 0;
uint8_t flashCfg = 0;
Expand Down Expand Up @@ -57,13 +57,13 @@ void SystemInit(void)
BL_WR_REG(GLB_BASE, GLB_PARM, tmpVal);

/* CLear all interrupt */
p = (uint32_t *)(CLIC_HART0_BASE + CLIC_INTIE_OFFSET);
p = (uint8_t *)(CLIC_HART0_BASE + CLIC_INTIE_OFFSET);

for (i = 0; i < (IRQn_LAST + 3) / 4; i++) {
p[i] = 0;
}

p = (uint32_t *)(CLIC_HART0_BASE + CLIC_INTIP_OFFSET);
p = (uint8_t *)(CLIC_HART0_BASE + CLIC_INTIP_OFFSET);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uint8_t is incorrect because with for (i = 0; i < (IRQn_LAST + 3) / 4; i++)

Copy link
Author

@mdednev mdednev May 26, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From e24 RISC-V core description:
изображение
изображение
registers are 1B width and address is computed as CLIC Hart Base + 1 × Interrupt ID, but as I see now the /4 devision should be removed. So cycle should be for (i = 0; i < IRQn_LAST; i++). I've missed this while making a patch.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use uint32_t to make it quickly.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uint32_t usage is incorrect, cause it will produce 4B aligned addresses while accessing pointer as array. CLIC registers are byte aligned, not word aligned and so their pointer type should be uint8_t *. Please look at provided figures.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mdednev CLIC_INTIE_OFFSET and CLIC_INTIP_OFFSET are both 4 byte aligned. the number of registers is evenly divisible by 4. they're all being set to 0 anyway.
As long as the cpu supports writing 32bit values here the original code should do the correct thing, right?
Is there something else here that we're not seeing?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mdednev CLIC_INTIE_OFFSET and CLIC_INTIP_OFFSET are both 4 byte aligned.

Yes, this is right.

the number of registers is evenly divisible by 4.

It depends on implementation and it isn't true in general. In other words this is error-prone way. So I've suggested more general and error-proof initialization code. Yes, it is little-bit slower, but it is more correct and matches e24 core registers description (1B registers should be accessed as 1B and not as 4B). For example SDK IRQ driver uses 1B accesses to this registers (drivers/lhal/src/bflb_irq.c):

void bflb_irq_disable(int irq)
{
#if defined(BL702) || defined(BL602) || defined(BL702L)
    putreg8(0, CLIC_HART0_BASE + CLIC_INTIE_OFFSET + irq);
#else
    csi_vic_disable_irq(irq);
#endif
}

they're all being set to 0 anyway. As long as the cpu supports writing 32bit values here the original code should do the correct thing, right? Is there something else here that we're not seeing?

Yes, this code works, but if it will be reused for future MCUs it could lead to errors in initialization.


for (i = 0; i < (IRQn_LAST + 3) / 4; i++) {
p[i] = 0;
Expand Down