What is Frame in ASP ?

SPRUED3 is probably the best document for this though I imagine it is what you are already looking at. The frame sync signal is similar to the clock signal in functionality, though it is a dimension higher than the clock as it pulses for each frame of data as opposed to each bit. A frame of data is a certain number of bits you define in your ASP configuration (XCR/RCR registers).

The frame signal allows the receiver to know when to start latching in bits and the transmitter to know when to start clocking out bits, without a frame signal the transmitter and receiver would have no way of agreeing on when the data should start, so they would not be able to align the bit stream into proper bytes and words.

A Frame Sync is a pulse on the FSX/FSR line that indicates the start of a frame of data.
A Frame (of Data) is an arbitrary amount of data you define in your ASP configuration registers.
A Frame Period is the number of bit clocks between Frame Syncs, this defines the theoretical maximum size of your frame of data, though your frame can contain less data than is available in the period.

Thank you Bernie,

 Although I am not 100% understood  why/how Frame works.. but your reply does help me to understand more about it.

Is there any code example for DM3x ASP?? 

 Thank you again!!

There is code for the ASP in the Linux audio driver (OSS), in particular the serial port portion can be found in lsp\ti-davinci\arch\arm\mach-davinci\mcbsp.c of your DVSDK kernel tree. Note that although this refers to mcbsp and DM6446 often it is actually using the ASP of the DM355 when built for the DM355. The ASP is a subset of the older McBSP functionality so the code was ported from an earlier platform that used an actual McBSP, and the DM355 ASP is almost identical to the DM6446 so it was ported to DM355 but kept much of the DM6446 nomenclature.

Thank  you for replying again.

 For some reason, I don't have those example , the one I have here is a custum made DM355 board.

All they gave me  is the board and CCS ver.3.2 .   oh yeah! and there is a CCS project which I can play around within " main() "

I finised reading 64 pages of ASP guide, and had understood more about it.

I dig into CCS examples, although there is no DM3x examples, but I do see McBSP or McASP code example for other processors.

But I found out that all these examples use CSL,  is it possible that I can enable ASP transfer function via Fill-in the registers?!

I will test Digital Loop-Back mode first,  will it work if I just follow the "General Initialization Procedure" in ASP guide (p.41)?

Thank You!

This is my ASP initialization step for Digital Loop Back mode: 

1.          Reset Everything:  RRST, XRST, GRST, and FRST

2.          Program the control registers as required:

*Digital LoopBack is enabled, CLKR and CLKX set to 1 for Internal sample rate generator.

*FSX & CLKX are enabled for DLB mode.

3.          *Select Clock Source: CLKSM=1 & SCLKME=0 for SAP internal input clock.

*Select CLKG divider value

*FSGM is set to 1 for Transmit frame-sync signal (FSX) driven by the sample-rate generator frame-sync signal (FSG).

4.          GRST is set to 1 to start sample rate generator, then wait for it gets ready.

5.          XRST set to 1 to clear any unexpected XSYNCERR error when device is reset,  then wait for while for error to occur, then set XRST back to 0 , this will clean error flag.

6.          Set both RRST & XRST to 1, now is ready for transmit/receive.

7.          Enable FRST by set it to 1, this starts the internal frame sync generator.

======================================================================

I assign a 8 bit value for DXR,  then this is what I got so far... 

0x01E02004 =DXR

0x01E02000=DRR

seems like DRR is successfully received data from DXR , right?? 

May I ask a stupid simple question... How do I read DRR to set RRDY to 0 , so it will receive the next data?!

THX

It looks like you have a good loop back test setup, the DXR and DRR matching is a good sign :). As to clearing RRDY, that should happen as soon as either your code or the EDMA performs a read on the DRR, note that the RRDY bit will be set again immediately after the next transfer is received in the DRR.

As to examples, the DM355 was designed to be used with a high level OS like Linux, the DM355 EVM includes Linux based software and drivers. This being said unfortunately we do not have any software collateral for using CCS for DM355 development, as you have shown it does work with CCS, we just don't have much support for CCS and DM355.

Simon Wu said:

 For some reason, I don't have those example , the one I have here is a custum made DM355 board.  

Having access to the software Bernie mentioned will be very helpful during your develoment phase; if anyone in your company has a registered DM355 EVM, they can get this software for you.  If not, I would strongly recommend buying one (I believe they are $495); the software includes Linux drivers for all major hardware peripherals that should greatly simplify your development even in your custom board.

Thank  you  Bernie and Juan , and Happy New Year!

 I think I will get involved with Linux Based DM355 soon... I don't know what kinda source they would give me.

 Anyway, I still have question with "reading DRR" .  

How DM355 determines it is a "READ" action?? 

what I do is like this :

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

 volatile Uint32* asp_ptr;

 asp_ptr= &DRR;     // DRR= 0x01E02000

 printf(" DDR is %#x  ! \n",*asp_ptr);

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

Does it considered to be a "READ" action??

If you are doing this on CCS (which I presume you are), the following

   Uint32 val;

   Uint32 i;

   *( volatile Uint32* )reg_addr = val

Will read the first word and address reg_addr and store it in val.

Any code that happens to access a value in DDR will initiate a DDR read (including direct pointers like this and code/variables that happen to be in DDR), though caching can minimize DDR accesses to the same variables (i.e. if you did this again and again you may only see the DDR read once). The read itself boils down to an assembly instruction generated by the compiler that accesses a location within the DDR space. The code you and Juan wrote should work to initiate a read, but keep in mind that if your application is located in DDR along with your heap and stack you will be reading from the DDR all the time.

Thank you all again, this is a really great place. 

I think I better  post my code up, cuz I really running into trouble with ASP without knowing why...

===  ASP Initialization call ===

void asp_init()
{

 // == Step 1 , RESET ==
 SPCR=0
 |(0<<0)  //RRST Reset
 |(0<<16) //XRST Reset
 |(0<<22) //GRST Reset
 |(0<<23);  // FRST Reset

 // ==  Step 2 Enable the necessary controller ==
 SPCR|=
 (1<<15) // Digital LoopBack
 ;
 PCR=0
 |(1<<8)  // CLKR , In DLB mode CLKR is an output pin and is driven
                 //by the transmit clock. The transmit clock is based on CLKXM bit.

 |(1<<9)  // CLKX
 |(1<<11) //  FSX
 ;   // must be enabled as outputs (CLKXM = FSXM = 1) in DLB mode

 
 // == Step 3 , Select Clock Source ==
 SRGR = 0
 |(1<<29)  // Select CLKSM
 ;

 PCR |=
 (0<<7)  // Select SCLKME
 |(1<<10) // FSRM , Frame-synchronization signal is generated internally by the sample-rate generator. FSR is an
    // output pin.
 |(1<<11) // FSXM , Frame-synchronization signal is determined by FSGM bit in SRGR.
 
 ;

 SRGR|=
 (99<<0) // CLKG divider value
 ;
 SRGR|=
 (1<<28) // FSGM
 ;

 // == Step 4, Start sample rate generator ==
 SPCR |=
 (1<<22) //GRST Reset
 ;

  _wait(20); //wait it ready

 
 // == Step 5 , clear any unexpect XSYNCERR error when device is reset
 SPCR|=
 (1<<16) //XRST Enabled
 ;
 _wait(20); //wait it ready

 SPCR|=
 (0<<16) //XRST Reset, this clear XSYNCERR error
 ;

 _wait(20); //wait it ready

 // == Step 6. Setup data acquisition method (EDMA , CPU )

 // == Step 7 , set ASP  ready to transmit and/or receive
 //        by polling the XRDY and/or RRDY bit in SPCR.
 
 SPCR |=
 (1<<0)  //RRST Reset
 |(1<<16) //XRST Reset
 ;

 // == Step 8 , Turn on Internal Frame Sync generator -=
 SRGR|=
 (1<<28) // FSGM 
 ;
 
 // == Step 9 ==

 // == Step 10  ==
  SPCR|=
 (1<<23)  // FRST Enabled
 ;

_wait(100);

}

==== In main() ====

 asp_init();  // === Initialize ASP===

count=0xD9;
 

for(i=0;i<50;i++)
{

 DXR=count--; 
 

printf(" DXR is %#x ! \n",DXR);

 asp_ptr=( Uint32* )(ASP_BASE);

 
  if (SPCR&0x00000002)  // == Check if RRDY is 1==
  {
      printf(" DRR is %#x ! \n",(volatile)*asp_ptr);
      printf("\n");
  }

asp_init();    // === For unknown Reason!! I have to re-initialize ASP ... in order to get new Data from DRR ....

// =====  Output =====

DXR is 0xca !
 DRR is 0xca !

 DXR is 0xc9 !
 DRR is 0xca !           ==*****  Here is Wrong!!! *****==

 DXR is 0xc8 !
 DRR is 0xc8 !

========================

So, I think I have two problems here,

1. Why do I have to re-initialize ASP in-order to get DRR to get new data.   If I don't re-intialize, it would receive the first data then stops... I think I must be missing something in my initialization steps.

2. After I call asp_init() again,  DDR updates its data,  but sometime it contains old data from DXR. I think sometimes  DRR doesn't update the data from DXR , or it maybe my code doesn't read DRR in some unkown occasion .

Thank you all again! I'm evaluating DM355 alone, so you guys are my only HOPE... : D