AER and ECU modules allocation

Stan Sidorov

Expert 1985 points

Hi there,

C5515

aer_c55l_cpuv3.3_obj_17_0_0_0

volib_C55_CPU3_2_1_0_1

CCS v5.5

I have some general questions:

1. Are there any specific requirements for AER modules and buffers to be allocated into the memory? I looked through the linker file in AER demo project and realized that every module as well as buffer is allocated quite specifically. However, there is no any reference in AER documentation. Should I follow the demo or I can do it in my own way?

2. ECU package from VoLIB requires specific allocation otherwise it just does not work. I found this feature by chance moving stuff around the memory. Are the any recommendation here? All ECU Data Memory Requirements I fulfilled but it does not matter. It depends on linker file. For example, in my case ECU works when

.text: {} > SAMEM4 PAGE 0 and nothing more in SAMEM4

Thanks

over 9 years ago

0 Jianzhong Xu over 9 years ago

TI__Mastermind 45920 points

Hi,

For your first question, there is AER integration guide in the docs folder, which talks about how to allocate buffers for AER.

Regards,

Jianzhong

0 Garrett Ding over 9 years ago in reply to Jianzhong Xu

TI__Mastermind 43296 points

Hi Stan,

For ECU buffer allocation, please refer to the "Echo Canceller: User’s Manual" section 5 - Integration, in volib_C55_CPU3_2_1_0_1\packages\ti\mas\ecu\docs\design, that provides guidelines users should follow regarding buffer placement in order to save MIPS.

Regards, Garrett

0 Stan Sidorov over 9 years ago in reply to Jianzhong Xu

Expert 1985 points

Hi Jianzhong,

Yes, there are some information in integration guide, but I am more interested in object specific allocation. If you look at aertest_c55l_ccs.cmd you can see that all AER objects are specifically allocated. So my questions are what is the importance of doing this and where is the guide describing such allocation?

aertest_c55l_ccs.rar

0 Stan Sidorov over 9 years ago in reply to Garrett Ding

Expert 1985 points

HI Garrett,

The question is not about saving MIPS. ECU just stops working when its objects in wrong place in the memory. I have prepared a simple test based on ECU demo project in order to show you the problem.

I tested that on 5515EVM and 5535EZDSP. VoLIB version volib_C55_CPU3_2_1_0_1

1. Go to test_rel_c55l_ccs.cmd

2. Comment out original MEMORY and SECTIONS blocks and paste suggested.

MEMORY
{

  DARAM    : origin = 0x02000, length = 0x0E000
  SARAM	   : origin = 0x010000, length = 0x040000

}

SECTIONS
{
  .sysstack > SARAM
  .stack    > SARAM
  .text     > SARAM
  .cinit    > SARAM
  .switch   > SARAM
  .bss      > SARAM
  .const    > SARAM
  .data     > DARAM
  .cio      > SARAM
  .sysmem   > SARAM
  .far      > DARAM

}

3. Launch the test and make sure that Sout is pure. ECU should work at this point.

4. Add this buffer anywhere, for example in ecusim.c:

tword test_buffer[15000];

5. Launch the test. When it is done check Sout. It is the same as Sin which means that ECU does not work.

I would like you to explain that. Why is it adding the buffer cases ECU stops working?

0 Garrett Ding over 9 years ago in reply to Stan Sidorov

TI__Mastermind 43296 points

Hi Stan,

With the memory map you defined and test_buffer added, I am seeing the error 'Can't Run Target CPU: WARNING: PAGE BOUNDARY CROSSING DETECTED AT PROGRAM COUNTER 0x1d37c' with C55xx simulator in CCS. This is probably why ECU doesn't work on EVM with your modification.

0x1d37c points to '$src\c55\ecudlnum.s:125:319$, ecu_dline_expand_seg' from disassembly window. The function ecu_dline_expand_seq() is the low-level PCM expansion routine. The routine will expand one continous "segment" of the delay line, and get expanded values using table lookup and write:

01d376:   809d24                   MOV *AR4(T0),*AR2-
01d379:   80bd24                   MOV *AR5(T0),*AR2-
01d37c:   80dd24                   MOV *AR6(T0),*AR2-
01d37f:   80fd24                   MOV *AR7(T0),*AR2-
01d382:   801d24                   MOV *AR0(T0),*AR2-

In C55x CPU revision 2.1/2.2, any addressing mode that increments or decrements a pointer (for example, *ARn+, *+AR(#k)) can potentially cause a wrap-around of the lower 16 bits (OFFSET) if the address crosses a page boundary, see here e2e.ti.com/.../42805 for details.

Regards,
Garrett

0 Stan Sidorov over 9 years ago in reply to Garrett Ding

Expert 1985 points

Hi Garrett,

Thank you for pointing out the problem. I am not sure about the solution, but I will definitely try to fix that based on your suggestion. Let you know about the result.

0 Stan Sidorov over 9 years ago in reply to Stan Sidorov

Expert 1985 points

Hi Garrett,

I have made some tests and ECU is happy when all its buffers as well as framework buffers are allocated within one page. So I hope I will not meet any new issues. It looks promising so far. Thank you.

Processors

Processors forum

AER and ECU modules allocation