Quantcast
Channel: Processors forum - Recent Threads
Viewing all 17527 articles
Browse latest View live

What is the recommended HPI initialization sequence for OMAP-L138?

$
0
0

In our project (custom board with OMAP-L138 and Spartan6) we have the following HPI initialization sequence (based on section 22.2.8 of OMAP-L138 DSP+ARM Processor Technical Reference Manual):

  1. Configure HPI pinmux
  2. Enable HPI in CFGCHIP1
  3. Set DUALHPIA and HWOB in HPIC (done by FPGA connected to OMAP)
  4. Configure FREE and SOFT bits in PWREMU_MGMT
  5. Release HPI from reset
  6. Verify that everything went correctly by checking if HWOB bit value changed (was written by FPGA)

Is this sequence correct? The problem is that we randomly (in about 4% cases) experience failure in step 6 (HWOB value is invalid) and we wonder if it's caused by some mistake in initialization sequence.


C6745 PCB SDRAM Layout

$
0
0

Using an SMD SDRAM on EMIFB, I have a feeling I blew the layout.

I matched all control signals within 0.5mm, DQM0/D0-7 within 0.2mm, DQM1/D8-15 within 0.2mm

But, the references I could find did not emphasize any relation between these three groups of signals, just match within the group.

CAS/RAS/CS0/A0-A12/BA0-BA1 = 37mm +/- 0.5mm

DQM0/D0-D7 17.5mm +/- 0.2mm

DQM1/D8-D15 42.5 +/- 0.2mm

WE/CKE/CLK 30mm +/- 0.5mm

1 x IS42S16800F-7TL SDRAM @128MHz/Latency=2

When I run, only the lower 8-bits gets read back from the SDRAM. The scope shows all lines with clean signal forms, though my setup is hard to do for multiple lines at once.

I ran the speed down to 60MHz and the same occurs.

OMAPL138 McBSP/DMA stability after DEEPSLEEP

$
0
0

Hi,

I am working on a project where we need to put the OMAP into deep sleep to save power. The processor appears to go in and out of deep sleep okay but communication over the McBSP with DMA seems to be unreliable. When it fails only the start of a message is received even though the sender has sent all the data. The McBSP (instance 1) is running at 48MHz and the OMAP at 456MHz (1.3V). I know that there is no data being sent into the OMAP on the McBSP at the time it goes into deep sleep as the last message before the port is blocked at source is the command to go into deep sleep. The port is blocked until we receive a message from the OMAP (over the same McBSP) saying it is awake. After the awake message is received by the controlling system it sends some more messages into the OMAP on the McBSP and it is these that are not fully received. I can connect with a debugger and see no McBSP or DMA errors.

When coming out of deep sleep are there any extra steps needed by the McBSP/DMA devices to allow them to work reliably?

Thanks

Nigel

Help with Memory Sharing Application

$
0
0

Hi,

I have been tracking down and issue for a long time and I' out of ideas. Hopefully can get some fresh things to try. I have an application modulating and demodulating a signal through the audio in and out of the OMAPL137 eval board from Spectrum Digital. I'm stress testing the protocol and am not able to pass some number of transmission without a considerable amount of errors. I actually have two EVM one sends data through the audio out, the second unit receives the data, echo it back and the first board demodulates and compares the data sent with the received. A simple loopback BER test. The code generates data in the ARM, signals the DSP to read it and modulate it, receives the data, demodulates it and store the received data into shared memory. All this is done running SYS/BIOS on both processors the ARM and the DSP.

I can run this routine for 10, 100, consistently with out any errors or with ver minimal errors. In the order ppm. When trying to test overnight, lets 100K times, some iteration will have a very high number of errors. I have set up the code to stop on high number of errors so I can look around the shared memory between the arm and the dsp. In my last findings the data makes it to the audio chip buffers but when looking into the shared ram, it is a bunch of garbage. This is after succesfully running for 1000 of times.

Well..... sorry for the long explanation.

I have added code to Cache_wbInvAll(); after the ARM writes to the shared memory and when the ARM reads from the shared memory. Is not the most efficient way but I do it just to be safe I'm actually looking at the real data and not something cached. I;m not doing a FIFO or buffer application but a very simple, put something in a share memory location, let the other side know is there to access it. As far as I can tell my code does not allow for multiple things to read or write from the shared location. 

Is there anything else I should be aware of or any guidance someone can hint me.  

Where are the sys/bios platform definitions?

$
0
0

Hi,

I have been using a custom platform and forgot where are the defaults, installed by sysbios located?

Any help will be greatly appreciated.

AM1808 connecting external clock against PRU function pin

$
0
0
Hi,

I have a question about AM1808 pin(A3).

My customer are connecting 48MHz external clock for USB_REFCLKIN against A3 pin of AM1808.
There two type of customer boards. One type of boards doesn't use USB_REFCLKIN, 
so this A3 pin are set to default function(PRU0_R31[17]) but 48MHz clock are still mounted 
and connected to this pin.

They want to know if there are any problem connecting 48MHz clock against PRU0_R31[17] function pin.
Are there any problem like device will get damaged or undesired operation?
By the way, they are not using PRU. best regards, g.f.

Memory Map issue + OMAPL137

$
0
0

Hello,

            We have evaluation board based on OMAPL137 and we have developed the custom board based on the same processor.

we have created simple UART test code which works fine in EVM board.

but when we tried to run same code in the custom board it gives verification error on SDRAM memory region.

The difference between EVM board and custom board is EVM has 64MB SDRAM and custom board has 32MB.

So we wanted to run the code from Internal Shared ram(128kb).

In EVM Board we didn't have Lcm But in Custom board due to above issue we tried to add LCM with all the sections residing in SHRAM.

while compiling we getting below mentioned error:

<Linking>
"./configPkg/linker.cmd", line 26: error #10264: IROM memory range overlaps

existing memory range SHDSPL2ROM
>> Compilation failure
"./configPkg/linker.cmd", line 27: error #10264: IRAM memory range overlaps
existing memory range SHDSPL2RAM
"./configPkg/linker.cmd", line 28: error #10264: L3_CBA_RAM memory range
overlaps existing memory range SHRAM
warning #10247-D: creating output section ".vecs" without a SECTIONS specification
warning #10247-D: creating output section "xdc.meta" without a SECTIONS specification
error #10010: errors encountered during linking; "VIJAY_HT_DSP.out" not built
gmake: *** [VIJAY_HT_DSP.out] Error 1
gmake: Target `all' not remade because of errors.

My questions are:

1) In which file the default memory map resides? how can i modify it?

2) If i create the new LCF file what changes should i make?

3) Can we run the code from internal RAM without using SDRAM.

 Thanks in advance.

Regards,

Vijay Hiremath

Unable to assert PRU EVTOUT1 on OMAPl138

$
0
0

I'm trying to assert the EVTOUT1 interrupt from PRU0 on to the OMAPL138 ARM core, to signal a completion event. I am so far unsuccessful in doing so. I would like this to be done on channel 3 of the interrupt controller for both the PRU and ARM.

I've attempted to follow the TI Interrupt Controller Wiki page to set up interrupts. Here is my PRU application code to generate the interrupt.

#include <stdint.h>
#include "pru_ctrl.h"
#include "pru_intc.h"

volatile register unsigned int __R30;
volatile register unsigned int __R31;

#define EVTOUT1			(3) //Event 3
#define PRU_CHANNEL		(3)
#define ARM_CHANNEL		(PRU_CHANNEL)
#define PRU_VEC_VALID   (1 << 5)

/// Map EVTOUT1
inline void initializeInterrupts(void)
{
	pruIntc CT_INTC;

	// Map event 3 to channel 3
	CT_INTC.CMR0_bit.CH_MAP_3 = PRU_CHANNEL;

	// Map channel 3 to host 3
	CT_INTC.HMR0_bit.HINT_MAP_3 = ARM_CHANNEL;

	// Ensure event 3 is cleared
	CT_INTC.SICR = EVTOUT1;

	// Enable event 3
	CT_INTC.EISR = EVTOUT1;

	// Enable Host interrupt 3
	CT_INTC.HIEISR |= EVTOUT1;

	// Enable Global Interrupts
	CT_INTC.GER = 1;
}

inline void announceCompletion(void)
{
	pruIntc CT_INTC;

	//Assert EVTOUT1
	__R31 = PRU_VEC_VALID | EVTOUT1;

	// Ensure event 3 is cleared
	CT_INTC.SICR = EVTOUT1;
}

void main(void)
{
	initializeInterrupts();
	announceCompletion();
}

Is there anything obviously wrong? One thing that I can think of is that the EVTOUT1 is mapped to the wrong event. The includes are the files that come from the PRU v4.0 SDK.

Thanks

Austin


EDMA to the McASP on the TMS320C6747 or OMAP-L137

$
0
0

Greetings!

Sorry for the repeat posting, in my first one, the format was quite wrong. 

I'm transmitting out of all 28 McASP Channels on the TMS320C6747. I'm working from a loop through example for the same chip.

I've created two dimensional ping pong buffers for both left and right channels of each McASP Channels.

It struck me that, perhaps I could do the 2d transfer with a single EDMA transmit channel, or perhaps one per MCASP, since the  XMT registers are continuous only within a single McASP. 

Question 1: Is it preferable/possible to have a single EDMA multidimensional transmission to the many output registers ? 

Question 2: Also, after reading the link below, I understand that while XBUFn are good registers for transmitting, that if transmitting through the DMA I should use a different address. Where can I find a memory map with these addresses ?

Initially, my intention was to setup a transmission such that each MCASP Channel is handled by it's own EDMA Transfer. If I go about it this way, I realize I'd need to make an additional argument to the setup_edma_pingpong_xmt functions to ensure they wrote to separate PaRAM:

for(int McASP_ind=0; McASP_ind<28; McASP_ind++)
    {
    	setup_edma_pingpong_xmt(xmt_ping_L[McASP_ind][0], xmt_pong_L[McASP_ind][0],
                            	xmt_ping_R[McASP_ind][0], xmt_pong_R[McASP_ind][0], mcasp_xmt_registers[McASP_ind],
				BYTES_PER_SAMPLE, BUF_LENGTH);
    }

Thank you!

EDMA can't copy data from DSPL2RAM to SDRAM.

$
0
0

I use EDMA to copy data from DSP memory to SDRAM, It works when copy data from SHRAM, but doesn't work
when copy data from DSPL2RAM to SDRAM.

here is the test code:

#pragma DATA_SECTION(sdram_buf, ".sdram_buf")
float sdram_buf[3];

typedef struct _EDMA{
    unsigned short region;
    unsigned short channel;
    unsigned int src;
    unsigned int dst;
    unsigned int nbytes;
    unsigned short src_inc;
    unsigned short dst_inc;
    unsigned short enable_event;
} EDMA;

EDMA edma_mem;

void setup_all_EDMA()
{
    edma_mem.region = 1;
    edma_mem.channel = 10;
    edma_mem.src_inc = 1;
    edma_mem.dst_inc = 1;
    edma_mem.enable_event = 0;
    EDMA_init(&edma_mem);
}

void EDMA_init(EDMA * e)
{
    edma3ccRegs->ECR |= 1 << (e->channel);
    edma3ccRegs->SECR |= 1 << (e->channel);

    if(e->enable_event){
        edma3ccRegs->EESR = 1 << (e->channel);
    }
    else{
        edma3ccRegs->EECR = 1 << (e->channel);
    }

    edma3ccRegs->DRA[e->region].DRAE |= 1 << (e->channel);

    edma3ccRegs->PARAMSET[e->channel].OPT = CSL_EDMA3CC_OPT_RESETVAL;

    edma3ccRegs->PARAMSET[e->channel].OPT =
        CSL_FMKT(EDMA3CC_OPT_TCINTEN, DISABLE) |
        CSL_FMKT(EDMA3CC_OPT_TCCHEN, DISABLE)  |
        CSL_FMK(EDMA3CC_OPT_TCC, e->channel);
}

void EDMA_clear_completed(EDMA * e)
{
    edma3ccRegs->ICR |= 1 << e->channel;
}

void EDMA_init_repeat(EDMA * e)
{
    Uint16 addr;

    if(e->enable_event){
        CSL_FINST(edma3ccRegs->PARAMSET[e->channel].OPT, EDMA3CC_OPT_STATIC, NORMAL);

        addr = (Uint32)(&edma3ccRegs->PARAMSET[e->channel + 64]) & 0xffff;
        edma3ccRegs->PARAMSET[e->channel].LINK_BCNTRLD =
            CSL_FMK(EDMA3CC_LINK_BCNTRLD_LINK, addr) |
            CSL_FMK(EDMA3CC_LINK_BCNTRLD_BCNTRLD, 0);

        memcpy((void *)&(edma3ccRegs->PARAMSET[e->channel + 64]),
               (void *)&(edma3ccRegs->PARAMSET[e->channel]),
               sizeof(CSL_Edma3ccParamSetRegs));

        edma3ccRegs->PARAMSET[e->channel + 64].A_B_CNT =
                CSL_FMK(EDMA3CC_A_B_CNT_ACNT, 1) |
                CSL_FMK(EDMA3CC_A_B_CNT_BCNT, 0);
    }
    else{
        CSL_FINST(edma3ccRegs->PARAMSET[e->channel].OPT, EDMA3CC_OPT_STATIC, STATIC);
        CSL_FINST(edma3ccRegs->PARAMSET[e->channel].OPT, EDMA3CC_OPT_TCINTEN, ENABLE);
    }
}

void EDMA_init_block_move(EDMA * e, Uint32 src, Uint32 dst, Uint32 nbytes)
{
    e->src = src;
    e->dst = dst;
    e->nbytes = nbytes;
    edma3ccRegs->PARAMSET[e->channel].CCNT = 1;
    edma3ccRegs->PARAMSET[e->channel].SRC_DST_BIDX =
        CSL_FMK(EDMA3CC_SRC_DST_BIDX_SRCBIDX, 0) |
        CSL_FMK(EDMA3CC_SRC_DST_BIDX_DSTBIDX, 0);

    edma3ccRegs->PARAMSET[e->channel].SRC_DST_CIDX =
        CSL_FMK(EDMA3CC_SRC_DST_CIDX_SRCCIDX, 0) |
        CSL_FMK(EDMA3CC_SRC_DST_CIDX_DSTCIDX, 0);

    edma3ccRegs->PARAMSET[e->channel].SRC = e->src;
    edma3ccRegs->PARAMSET[e->channel].DST = e->dst;

    edma3ccRegs->PARAMSET[e->channel].A_B_CNT =
        CSL_FMK(EDMA3CC_A_B_CNT_ACNT, e->nbytes) |
        CSL_FMK(EDMA3CC_A_B_CNT_BCNT, 1);

    EDMA_init_repeat(e);
}

void EDMA_block_move(EDMA * e)
{
    edma3ccRegs->ECR |= 1 << (e->channel);

    edma3ccRegs->PARAMSET[e->channel].A_B_CNT =
        CSL_FMK(EDMA3CC_A_B_CNT_ACNT, e->nbytes) |
        CSL_FMK(EDMA3CC_A_B_CNT_BCNT, 1);

    edma3ccRegs->ESR |= 1 << (e->channel);
}

void test_edma_sdram()
{
    SDRAM_F32(0) = 0;
    SDRAM_F32(1) = 0;
    SDRAM_F32(2) = 0;
    sdram_buf[0] = 3.14f;
    sdram_buf[1] = 3.14f * 2;
    sdram_buf[2] = 3.14f * 3;
    EDMA_clear_completed(&edma_mem);
    EDMA_init_block_move(&edma_mem, (Uint32)sdram_buf,
            SDRAM_BASE, sizeof(sdram_buf));
    EDMA_block_move(&edma_mem);
    while(!EDMA_is_completed(&edma_mem)){
    }
}



Here is the CMD file:

MEMORY
{
    ...
    DSPL2RAM     o = 0x00804000  l = 0x0003C000     /* 256kB L2 Internal RAM */
    SHRAM        o = 0x80000000  l = 0x00020000     /* 128kB Shared RAM */                   
    ...
}                                                                       

SECTIONS
{
    ...
    .far           >  DSPL2RAM
    .sdram_buf     >  SHRAM
    ...
}



It works when I put sdram_buf to SHRAM, but if I comment out the #param DATA_SECTION line, sdram_buf is
put in to .far section(DSPL2RAM) and it don't work. All the data in SDRAM are zero.

it costs about 500ns to start a memory to memory EDMA, is it normal?

$
0
0

I am trying to speed up copying data from inner memory to SDRAM, the DSP works at 400MHz. It seem it costs >500ns to set and start the EDMA, for example following code costs 134 CPU clock, it's about 340ns:

edma3ccRegs->PARAMSET[10].DST = DST;  
edma3ccRegs->ESR |= 1 << 10;   

However, write 16bytes to SDRAM by CPU only costs 42 CPU clock.

it seems that there is no benefit to use EDMA to copy the data if the data size is small.

In my applicaiton I need to copy about 64 bytes from inner memory to SDRAM every 5us. I want to do this as fast as possible.

C6Caccel - how to get extra error information, iUniversal returns -7 - what is this error ?

$
0
0

Dear TI

I am trying to extend c6accel to call an example function.

I am getting as far as calling the iUniversal Process call on the ARM but it is returning status -7 ; 

I found the xdm.h header file but it goes as far as -5  -

How can I get some more information regarding  the eror ?

All the best

OMAPL137 Toggling the GPIO from the ARM Side in SYSBIOS

$
0
0
Would it be better to start a new thread?

I'm still having issue trying to toggle an LED on the EVM OMAPL137 with SYS BIOS on the ARM. I can run the rCSL example but I'm not able to do it when running with SYS/BIOS. On the other hand I have ported to SYSBIOS the GPIO example from the rCSL folder, for the DSP side. Has been my DSP heartbeat all along. I'm trying to do the same on the ARM, is always nice to have a visual heartbeat.

Any suggestion will be greatly appreciated.

AM1808 Code composer studio OUT file to real flash HEX(binary) converting problem

$
0
0

I want AM1808 Code composer studio OUT file to real flash HEX(binary) converting.

"out2rprc" tool is not same flash data. Maybe is uart boot loader(UBL) spec.

OMAP-L138 SATA: not transmiting data from DMA to system memory .(Code Composer Studio )

$
0
0

Hi,  I am using SATA test code from LogicPD ( BSL code package) and user cases from reference manual. After function :

submitCmd (NON_QUEUED_CMD, cmdSlot2Use);

I am first receiving data, they are copying into memory (prdTableDataBuff [512] ).

Next, i am changing address in Fis and try reading again:

           CmdSlotNum->cfis.DW1.B0LbaLow=myCmdFis.cfisDw1SecNumLbaLow;  //correct address
           CmdSlotNum->cfis.DW1.B1LbaMid=myCmdFis.cfisDw1CylLowLbaMid;
           CmdSlotNum->cfis.DW1.B2LbaHigh=myCmdFis.cfisDw1CylHighLbahigh;
           CmdSlotNum->cfis.DW1.B3Device=myCmdFis.cfisDw1Dev;

           submitCmd (NON_QUEUED_CMD, cmdSlot2Use);

I am getting the correct data block in L1D cache, but not in system memory.

Also, i can change RXABL and TXABL bits in Port DMA Control Register (P0DMACR) , but i can't change RXTS and TXTS (0x4 always!).

Regards, 

Ilya


OMAP L138, C6748 setup GPIO3[0:7] but not working

$
0
0

Hi there,

We are working on OMAPL138 LCDK to connect other device through GPIO. I am trying to use GPIO3[0:7] pins through configuring PINMUX8 from DSP end. The pins are available in expansion header J14.

I started with GPIO example from CSL library which is using GPIO0[7] and works as expected. Then I modified the example to use GPIO3[0] (if it worked, I would configure other ports on GPIO bank 3). However, GPIO3[0] was not working (interrupts were not triggered ).

Just want to check

1/ if GPIO3[0] pin and other GPIO3 pins are open for users to use?

2/ Do these pins have to be EMA_D[8:15] which appear in PCB schematic layout?

3/ GPIO8[10] and GPIO[12] appear in J15 expansion header according to PCB schematic layout. but, why is GPIO8 not completely defined in CSL library? Before using GPIO8, I just want to check if GPIO8[10] and [12] are also open for users to use?

Cheers,

Louie

L138/C6748 LCDK: Which Starterware?

$
0
0

On the Starterware page, we have found an L138 version and a C6748 version. Does the L138/C6748 LCDK prefer one over the other?

Mike Briggs

Implementing File system for saving video onto Sd card

$
0
0

Hi,


I am working with the OMAPL138 LCDK for the first time. Thanks to help from many like Titus in this forum, I have been able to do a lot of examples that came with the starterware. My objective is to record videos on sd card. If I am not wrong, I would need to use RTOS for this right? If so which one MCSDK or SYSBIOS?

I have never implemented a FAT file system. I did not find any examples also of mmc for this board. Are there any resources of TI on File system implementation ?

 

thanks

Vivek

Problem with higher CPU Clock frequency(360MHz, 372MHz,420MHz or 444MHz) in OMAPL138

$
0
0

Hi,

We have made Custom boards using OMAPL138 Chip-set. This Chip-set is rated to operate at 450MHz(CPU Frequency).

Till now we are using this with DaVinci PSP 03.20.00.11 SDK.
- linux version is 2.6.33-rc4
- u-boot version is U-Boot 2009.11
- Compiler version is gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203)

The Boards we are using, runs with external clock source as 24MHz.

We are inserting custom modules in the linux which will access uPP module frequently. We are observing two problems

1. uPP underflow error - If clock Source of ASYNC3 domain is kept as PLL1.
2. Random kernel crashes - If clock Source of ASYNC3 domain is kept as PLL0.

If CPU Clock frequency(Sourced from PLL0) is configured to 300MHz, everything is  working fine.

But If we move to Higher CPU clock(i.e 360MHz, 372MHz,420MHz or 444MHz), we were seeing uPP under-run problem in most of the boards.
but some boards were working fine without uPP under-run problem even at 444MHz.

By default, in linux, clock Source of ASYNC3 domain was moved from PLL0 to PLL1(in SOURCE_DIR/arch/arm/mach-davinci/da850.c) during linux boot-up. So as a fix for uPP under-run problem, we tried not to move the clock Source of ASYNC3 domain to PLL1 but used PLL0 as clock Source of ASYNC3 domain.

With this change we didn't see any uPP under-run problem, but we are seeing random kernel crashes in all the boards at clock higher than 300Mhz.

One of the crash log has been attached. If we move the ASYNC source from PLL0 to PLL1, then this random crash is not observed, but uPP under-run issue is observed.

(Please visit the site to view this file)

In summary, problems observed at higher clocks(anything other than 300MHz ):
1. uPP underflow error - If clock Source of ASYNC3 domain is kept as PLL1.
2. Random kernel crashes - If clock Source of ASYNC3 domain is kept as PLL0.

Please let us know if any thing is missed out or anyone has observed similar issues, any pointers to help resolve these issues is highly appreciated.

NOTE:

All Frequency change are verified with the OMAP clocking validation spreadsheet provided in TI website downloaded from

http://processors.wiki.ti.com/index.php/Programming_PLL_Controllers_on_OMAP-L1x8/C674x/AM18xx

the problem with use NDK in omapl138

$
0
0

I have some problems about using NDK,as this.

1. PC IP addr : 192,168,20.45 ,Subnet mask : 255.255.0.0.

2. Embedded devices  IP addr : 192.168.60.198, Subnet mask : 255.255.255.0,this Embedded devices using NDK module,we hypothesis it's Dev 1 at here.

3. Dev 1 as service ,and PC as client( common network tools on pc)

4.by using network tools ,I find PC  can communication with Dev 1, just I don't know that's why,can you tell me?

 

my environment is:

1. CCS version v5.5

2. BIOS version 6.37.2.72,XDC tools 3.25.5.94

3. NDK version 2.24.3.35, NSP 1.10.2.9

 

Viewing all 17527 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>