[BSP] os/arch/arm/src/amebasmart: TDM implementation for linked-list dma buff #6991

zhongnuo-tang · 2025-10-01T02:32:04Z

includes changes in PR6969
includes changes in PR6968
fixed issue where data in app cannot be found in LA.
All data printed in application can be found in LA, some data between two i2s receive are discarded because i2s clk is always on, it continue sampling but not callback to application layer.

1. includes changes in PR6969 2. includes changes in PR6968 3. fixed issue where data in app cannot be found in LA. 4. All data printed in application can be found in LA, some data between two i2s receive are discarded because i2s clk is always on, it continue sampling but not callback to application layer.

namanjain7

We verified the PR.

the 17th data is not matched.

Also, since it's left justified TDM, so, we should set the 0x2E register value as 0x02.

+++ b/os/drivers/sensors/ais25ba.c

@@ -263,7 +263,7 @@ static void ais25ba_i2c_write_data(struct i2c_dev_s *i2c, struct i2c_config_s co

        }

        usleep(1000 *100);

        reg[0] = 0x2E;

-       reg[1] = 0x62;

+       reg[1] = 0x02;

        ret = i2c_writeread(i2c, &config, (uint8_t *)reg, 2, data, 0);

        if (ret != 2) {

                sndbg("ERROR: I2C writeread failed, reg_addr: %p  %p\n", reg[0], reg[1]);

zhongnuo-tang · 2025-10-01T09:06:44Z

We verified the PR.

the 17th data is not matched.

Also, since it's left justified TDM, so, we should set the 0x2E register value as 0x02.

+++ b/os/drivers/sensors/ais25ba.c

@@ -263,7 +263,7 @@ static void ais25ba_i2c_write_data(struct i2c_dev_s *i2c, struct i2c_config_s co

        }

        usleep(1000 *100);

        reg[0] = 0x2E;

-       reg[1] = 0x62;

+       reg[1] = 0x02;

        ret = i2c_writeread(i2c, &config, (uint8_t *)reg, 2, data, 0);

        if (ret != 2) {

                sndbg("ERROR: I2C writeread failed, reg_addr: %p  %p\n", reg[0], reg[1]);

Hi @namanjain7 could you share the mismatched data?
logs maybe?
and is there any other changes different from this PR? Lets synced to avoid misunderstanding

namanjain7 · 2025-10-01T09:20:29Z

We verified the PR.
the 17th data is not matched.
Also, since it's left justified TDM, so, we should set the 0x2E register value as 0x02.
+++ b/os/drivers/sensors/ais25ba.c

@@ -263,7 +263,7 @@ static void ais25ba_i2c_write_data(struct i2c_dev_s *i2c, struct i2c_config_s co

        }

        usleep(1000 *100);

        reg[0] = 0x2E;

-       reg[1] = 0x62;

+       reg[1] = 0x02;

        ret = i2c_writeread(i2c, &config, (uint8_t *)reg, 2, data, 0);

        if (ret != 2) {

                sndbg("ERROR: I2C writeread failed, reg_addr: %p  %p\n", reg[0], reg[1]);
Hi @namanjain7 could you share the mismatched data? logs maybe? and is there any other changes different from this PR? Lets synced to avoid misunderstanding

Only 0x2E register value is changed to 0x02. Other code is same as the PR.

Logs data:

0033 fef5 1ede
0030 fef9 1ed2
0031 fefd 1ece
0031 ff00 1ed4 ----> Matched data till here

0034 ff00 1f07 ----> Mismatched data
0030 ff05 1f05
002e ff09 1f0d
002d ff08 1f0e
002a ff03 1f10
0029 fefb 1f10
0028 fef6 1f17

Sal data:
8.482356840000000,1,0x0030,0x00
8.482364640000000,2,0xFEF9,0x00
8.482372460000001,3,0x1ED2,0x00
8.482380279999999,4,0x0000,0x00
8.482388080000000,5,0x0000,0x00
8.482395900000000,6,0x0000,0x00
8.482403720000001,7,0x0000,0x00
8.482411519999999,8,0x0000,0x00
8.482419340000000,1,0x0031,0x00
8.482427140000000,2,0xFEFD,0x00
8.482434960000001,3,0x1ECE,0x00
8.482442780000000,4,0x0000,0x00
8.482450580000000,5,0x0000,0x00
8.482458400000001,6,0x0000,0x00
8.482466219999999,7,0x0000,0x00
8.482474020000000,8,0x0000,0x00
8.482481840000000,1,0x0031,0x00
8.482489640000001,2,0xFF00,0x00
8.482497459999999,3,0x1ED4,0x00
8.482505280000000,4,0x0000,0x00
8.482513080000000,5,0x0000,0x00
8.482520900000001,6,0x0000,0x00
8.482528719999999,7,0x0000,0x00
8.482536520000000,8,0x0000,0x00 -----> Match till here.

8.482544340000000,1,0x0033,0x00 ----> Mismatch from here.
8.482552139999999,2,0xFF01,0x00
8.482559960000000,3,0x1EDA,0x00
8.482567780000000,4,0x0000,0x00
8.482575580000001,5,0x0000,0x00
8.482583399999999,6,0x0000,0x00
8.482591220000000,7,0x0000,0x00
8.482599020000000,8,0x0000,0x00
8.482606840000001,1,0x0035,0x00
8.482614659999999,2,0xFF01,0x00
8.482622460000000,3,0x1EE1,0x00
8.482630280000000,4,0xFFFF,0x00
8.482638079999999,5,0xFFFF,0x00
8.482645900000000,6,0xFFFF,0x00
8.482653720000000,7,0xFFFF,0x00
8.482661520000001,8,0xFFFF,0x00
8.482669339999999,1,0x0036,0x00
8.482677160000000,2,0xFEFE,0x00
8.482684960000000,3,0x1EE7,0x00
8.482692780000001,4,0xFFFF,0x00
8.482700579999999,5,0xFFFF,0x00
8.482708400000000,6,0xFFFF,0x00
8.482716220000000,7,0xFFFF,0x00
8.482724019999999,8,0xFFFF,0x00
8.482731840000000,1,0x0036,0x00

zhongnuo-tang · 2025-10-01T09:29:18Z

0033 fef5 1ede

How many samples are correct? when you said 17th data does it mean 17th (512bytes) or 175h(16bytes)?

1. linked list dma is used, page number is 16, page size now hard coded to sync with application of 512 bytes. So INT and EXT both use 256bytes. 2. When all dma page are full, data will be discarded instead of overwrite. 3. verified with printing only 4 frames in application, matched with LA. eg: app request 32*16 bytes, i will only print 4*16 bytes to avoid delays, then compare with LA data 4*16bytes.

zhongnuo-tang · 2025-10-01T10:04:54Z

Hi @namanjain7 ,
I have added a new commit for linked-list.
Please check my replies in email and help to test again

1. remove static buffer implementation

namanjain7 · 2025-10-08T06:21:58Z

ALL data is correctly received and matched with sal graph. PR is working fine.

allen-kim-sec

It looks good to merge , pass off the 1st step..

allen-kim-sec · 2025-10-13T04:16:10Z

@zhongnuo-tang , ( cc to @namanjain7 )

To establish the codebase, I initially merged this PR; however, there is a mismatch in the data at frame 65. Eventually, when observing in LA, the data pattern can be found at frame 1600.
As a result, frames 1 to 64 pass, but show 65 frame data from console is actual 1600 frame's data
Please create a new PR for the necessary corrections.

consider two points
1. integratation failure at the BSP side
2. not high priority to provide apb for BSP over margin 96 msec case

zhongnuo-tang · 2025-10-13T04:22:05Z

@zhongnuo-tang , ( cc to @namanjain7 )

To establish the codebase, I initially merged this PR; however, there is a mismatch in the data at frame 65. Eventually, when observing in LA, the data pattern can be found at frame 1600. As a result, frames 1 to 64 pass, but show 65 frame data from console is actual 1600 frame's data Please create a new PR for the necessary corrections.

consider two points

integratation failure at the BSP side

not high priority to provide apb for BSP over margin 96 msec case

Hi @namanjain7 ,
I believe we had verified that the data is 1-1 match between app and LA isnt it?
Hi @allen-kim-sec ,
Could you explain abit more for the two points mentioned, I don't quite understand..

allen-kim-sec · 2025-10-13T10:37:10Z

I think we can easily resolve this problem by Increasing APB queue before starting TDM communication..
@namanjain7 reported that he confirmed it when application only show 4 frames.
driver side should provide a solution to prevent missing frame more.
he will profile bad and good conditions and will test the maxium margin.

allen-kim-sec · 2025-10-13T11:24:49Z

@zhongnuo-tang
we will find solution to prevent missing frames in the application and driver side... to get more margin.
No matter how hard we try, if we cannot guarantee stable operation, we need to increase the GDMA page size in the BSP.
A larger page size provides us with more margin for flexibility.

zhongnuo-tang · 2025-10-14T01:51:51Z

@zhongnuo-tang we will find solution to prevent missing frames in the application and driver side... to get more margin. No matter how hard we try, if we cannot guarantee stable operation, we need to increase the GDMA page size in the BSP. A larger page size provides us with more margin for flexibility.

understood, please let me know if adjustment of page size is required.
If we need a larger page size, then porting layer need to be modified when copying data from DMA to apb buffer. Current implementation assumes each page size <= app's apb buffer size, so no slicing is done.

namanjain7 suggested changes Oct 1, 2025

View reviewed changes

os/arch/arm/src/amebasmart: clean up code

301f17c

1. remove static buffer implementation

zhongnuo-tang changed the title ~~[DO NOT MERGE] os/arch/arm/src/amebasmart: TDM implementation for single dma buff~~ [DO NOT MERGE] os/arch/arm/src/amebasmart: TDM implementation for linked-list dma buff Oct 6, 2025

allen-kim-sec approved these changes Oct 13, 2025

View reviewed changes

allen-kim-sec merged commit 2337379 into Samsung:TDM Oct 13, 2025
9 of 11 checks passed

allen-kim-sec changed the title ~~[DO NOT MERGE] os/arch/arm/src/amebasmart: TDM implementation for linked-list dma buff~~ [BSP] os/arch/arm/src/amebasmart: TDM implementation for linked-list dma buff Oct 20, 2025

[BSP] os/arch/arm/src/amebasmart: TDM implementation for linked-list dma buff #6991

[BSP] os/arch/arm/src/amebasmart: TDM implementation for linked-list dma buff #6991

Uh oh!

Conversation

zhongnuo-tang commented Oct 1, 2025

Uh oh!

namanjain7 left a comment

Choose a reason for hiding this comment

Uh oh!

zhongnuo-tang commented Oct 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

namanjain7 commented Oct 1, 2025

Uh oh!

zhongnuo-tang commented Oct 1, 2025

Uh oh!

zhongnuo-tang commented Oct 1, 2025

Uh oh!

namanjain7 commented Oct 8, 2025

Uh oh!

allen-kim-sec left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

allen-kim-sec commented Oct 13, 2025

Uh oh!

zhongnuo-tang commented Oct 13, 2025

Uh oh!

allen-kim-sec commented Oct 13, 2025

Uh oh!

allen-kim-sec commented Oct 13, 2025

Uh oh!

zhongnuo-tang commented Oct 14, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

zhongnuo-tang commented Oct 1, 2025 •

edited

Loading