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

How core available in this processor?

$
0
0

hi sir,

           This is what type of processor ? single core processor or dual core processor ?

                                            


AM6548: PCIe transaction size

$
0
0

Part Number:AM6548

Hi Team,

 

What is the maximum transaction size? Is it 128 bytes?

What is the maximum payload size?

 

Thanks and Best regards,

Kuerbis

AM6548: USB0 Device enumeration issue

$
0
0

Part Number:AM6548

Hi Team,

We have designed a board with AM6548 Processor. We are in board bring up stage.

Currently, we are facing an issue with AM6548 USB0 Interface.

USB0 is working fine in Host Mode. However in device mode we are facing an issue with device enumeration.

We have followed EVM as reference for schematic design.

Kindly share your thoughts on this.

Thank you.

Regards,

Sushruta

Linux/DRA745: vsdk sd boot issue in customer board

$
0
0

Part Number:DRA745

Tool/software: Linux

Hi,experts

In customer board, when boot from sd, encountered below issue

U-Boot SPL 2016.05-00003-ga6ba0dc-dirty (Jun 06 2019 - 18:40:36)
DRA722-HS ES2.0Trying to boot from MMC1
spl: loading remote core image dra7-ipu2-fw.lzop
mmc 1 mode HS(sd)
part_init: try 'EFI': ret=-1
part_init: try 'DOS': ret=-1
CACHE: Misaligned operation at range [80a01174, 80a01974]
** First descriptor is NOT a primary desc on 0:1 **
part_init: try 'ISO': ret=-1
mmc_init: 0, time 97 (retries 0)
## Unknown partition table type 0
** Partition 1 not valid on device 0 **
spl_register_fat_device: fat register err - -1
spl: error reading image dra7-ipu2-fw.lzop, err - -1
Error loading remotecore IPU2!,Continuing with boot ...
spl: mmc boot mode: fs
## Unknown partition table type 0
** Partition 1 not valid on device 0 **
spl_register_fat_device: fat register err - -1
spl_load_image_fat: error reading image u-boot.img, err - -1
## Unknown partition table type 0
spl: no partition table found
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

could you help to check ? The project is urgent.

TMS320C6455: TMS320C6455 CVdd power supply

$
0
0

Part Number:TMS320C6455

Dear Sir/Madam,

we are using TMS320C6455 850MHz processor, powering it's core CVdd with 1.2V power supply. What will happen, if we use 1GHz TMS320C6455 processor (which requires 1.25V according the datasheet) instead, powering it with the same 1.2V? Considering it will have the same 850MHz application to run. Can 1GHz/1.2GHz DSP work on 1.2V core supply using lower speed?

Best regards,

Arkadijs

RTOS/AM5728: Remoteproc error

$
0
0

Part Number:AM5728

Tool/software: TI-RTOS

Hi,

So I have this project where I use the EMAC driver together with ipc / remoteproc. It works fine when I run it compilted with debug configuration, but when I change to the release configuration I get the following error when I try to load the program with remoteproc:

erroneous trace resource entry

Failed to process resources: -22

Probably something gets optimized away. I followed this guide to set the application up, so any ideas where it might need a volatile?

If it helps, here the project code

(Please visit the site to view this file)

CCS/AM5718: XDS110 detect error

$
0
0

Part Number:AM5718

Tool/software: Code Composer Studio

Hi All,

We are using XDS110 debugger for a board based on AM5718. The debugger is not connecting to the JTAG port.All power and clocks to th eprocessor are proper. We tried reducing the TCK to 100 KHz but still it didn't work. Also the TRST voltage was around 1.7V with 4.7K pull down. Changed the resistor value to 10K but the voltage on TRST pin didnt change. Even a pullup of 10K to 3.3 Volt didnt help.

The error log is as:

[Start: Texas Instruments XDS110 USB Debug Probe_0]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

[Result]


-----[Print the board config pathname(s)]------------------------------------

C:\Users\senthilk\AppData\Local\TEXASI~1\
    CCS\ti\0\0\BrdDat\testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 100- or 510-class product.
This utility will load the adapter 'jioxds110.dll'.
The library build date was 'Nov  6 2017'.
The library build time was '10:36:36'.
The library package version is '7.0.100.0'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '5' (0x00000005).
The controller has an insertion length of '0' (0x00000000).
This utility will attempt to reset the controller.
This utility has successfully reset the controller.

-----[Print the reset-command hardware log-file]-----------------------------

The scan-path will be reset by toggling the JTAG TRST signal.
The controller is the XDS110 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for XDS110 features.
The controller cannot monitor the value on the EMU[0] pin.
The controller cannot monitor the value on the EMU[1] pin.
The controller cannot control the timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '0' (0x0000).

-----[An error has occurred and this utility has aborted]--------------------

This error is generated by TI's USCIF driver or utilities.

The value is '-233' (0xffffff17).
The title is 'SC_ERR_PATH_BROKEN'.

The explanation is:
The JTAG IR and DR scan-paths cannot circulate bits, they may be broken.
An attempt to scan the JTAG scan-path has failed.
The target's JTAG scan-path appears to be broken
with a stuck-at-ones or stuck-at-zero fault.

[End: Texas Instruments XDS110 USB Debug Probe_0]

Thanks and Regards

Rajneesh

Linux/TDA2SX: Peripheral Device Flashing over USB Interface

$
0
0

Part Number:TDA2SX

Tool/software: Linux

Dear TI,

I am now trying to flashing eMMC over USB interface.

My operations:
step1: host$ sudo ./usbboot -S spl/u-boot-spl.bin

step2: set sw2[7:0] at cpu board as [0 0 0 0 0 0 0 0], and then power on the evm.

host machine output:

reading ASIC ID
CHIP: 5641
rom minor version: 02
IDEN: 0000000000000000000000000000000000000000
MPKH: 0000000000000000000000000000000000000000000000000000000000000000
CRC0: 51d2f9a7
CRC1: 00000000
device is GP
sending 2ndstage to target...



evm output:

U-Boot SPL 2016.05-00008-g1fbee98-dirty (Jun 06 2019 - 20:35:16)
DRA752-GP ES2.0
Trying to boot from USB DFU
Using default environment

UNKNOWN IRQ type 1715168365                    <----------------------It looks like an USB IRQ error showing from the code, but i don't know why.

step3:  host$   sudo dfu-util -l

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to sourceforge.net/.../

Found DFU: [0451:d022] ver=0223, devnum=38, cfg=1, intf=0, path="1-7", alt=2, name="ramdisk", serial="UNKNOWN"
Found DFU: [0451:d022] ver=0223, devnum=38, cfg=1, intf=0, path="1-7", alt=1, name="fdt", serial="UNKNOWN"
Found DFU: [0451:d022] ver=0223, devnum=38, cfg=1, intf=0, path="1-7", alt=0, name="kernel", serial="UNKNOWN"

step4: host$ sudo dfu-util -D boot.img -c 1 -i 0 -a 0    

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to sourceforge.net/.../

dfu-util: File size is too big: Success

The file boot.img was generated by issue:

           dd if=/dev/sdb1 of=boot.img bs=1M count=4096 &

           dd if=/dev/sdb2 of=boot.img bs=1m count=4096 &

/dev/sdb1 & /dev/sdb2 are my bootable SD card device. I just replaced uenv.txt in the boot partition with uenv-emmc.txt.

step5:  host$ sudo dfu-util -D u-boot.img -c 1 -i 0 -a 0  -R                  <-----------------------------------------I try to debug the problem show in step 4. 

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to sourceforge.net/.../

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0451:d022
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 4096
Copying data from PC to DFU device
Download    [=========================] 100%       837964 bytes
Download done.
state(7) = dfuMANIFEST, status(0) = No error condition is present
state(2) = dfuIDLE, status(0) = No error condition is present
Done!

step 6: target output:

U-Boot 2016.05-00008-g1fbee98-dirty (Jun 06 2019 - 20:35:16 +0800)

CPU  : DRA752-GP ES2.0
Model: TI DRA742
Board: DRA74x EVM REV H.0
DRAM:  4 GiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
** First descriptor is NOT a primary desc on 1:1 **
*** Warning - bad CRC, using default environment

GUID Partition Table Header signature is wrong: 0x0 != 0x5452415020494645
part_get_info_efi: *** ERROR: Invalid GPT ***
GUID Partition Table Header signature is wrong: 0x0 != 0x5452415020494645
part_get_info_efi: *** ERROR: Invalid Backup GPT ***
ERROR: cannot find partition: 'userdata'

at arch/arm/cpu/armv7/omap-common/utils.c:195/mmc_get_part_size()
Warning: fastboot.userdata_size: unable to calc
SCSI:  SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst
scanning bus for devices...
Found 0 device(s).
Net:   
Warning: ethernet@48484000 using MAC address from ROM
eth0: ethernet@48484000
Hit any key to stop autoboot:  0
=>

step7: uboot $ printenv

=> printenv
arch=arm
args_fit=setenv bootargs console=${console}
args_mmc=run finduuid;setenv bootargs console=${console} ${optargs} root=PARTUUID=${uuid} rw rootfstype=${mmcrootfstype}
baudrate=115200
board=dra7xx
board_name=dra7xx
board_rev=H.0
boot_fdt=try
boot_fit=0
boot_os=0
bootargs=androidboot.serialno=${serial#} console=ttyS0,115200 androidboot.console=ttyS0 androidboot.hardware=jacinto6evmboard
bootcmd=if test ${dofastboot} -eq 1; then echo Boot fastboot requested, resetting dofastboot ...;setenv dofastboot 0; saveenv;echo Booting into fastboot ...; fastboot 0; fi;if test ${boot_fit} -eq 1; then run update_to_fit;fi;run findfdt; run envboot; run mmcboot;run emmc_android_boot;
bootdelay=2
bootdir=/boot
bootenvfile=uEnv.txt
bootfile=zImage
bootm_size=0x10000000
bootpart=0:2
bootscript=echo Running bootscript from mmc${mmcdev} ...; source ${loadaddr}
console=ttyO0,115200n8
cpu=armv7                                                 --------------------------------------------------------The size of boot.img is 4GB, so i modify the rawemmc raw parameters. I don't know whether it's right or not.
dfu_alt_info_emmc=rawemmc raw 0 4294967296;boot part 1 1;rootfs part 1 2;MLO fat 1 1;MLO.raw raw 0x100 0x100;u-boot.img.raw raw 0x300 0x1000;u-env.raw raw 0x1300 0x200;spl-os-args.raw raw 0x1500 0x200;spl-os-image.raw raw 0x1700 0x6900;spl-os-args fat 1 1;spl-os-image fat 1 1;u-boot.img fat 1 1;uEnv.txt fat 1 1
dfu_alt_info_mmc=boot part 0 1;rootfs part 0 2;MLO fat 0 1;MLO.raw raw 0x100 0x100;u-boot.img.raw raw 0x300 0x1000;u-env.raw raw 0x1300 0x200;spl-os-args.raw raw 0x1500 0x200;spl-os-image.raw raw 0x1700 0x6900;spl-os-args fat 0 1;spl-os-image fat 0 1;u-boot.img fat 0 1;uEnv.txt fat 0 1
dfu_alt_info_qspi=MLO raw 0x0 0x040000;u-boot.img raw 0x040000 0x0100000;u-boot-spl-os raw 0x140000 0x080000;u-boot-env raw 0x1C0000 0x010000;u-boot-env.backup raw 0x1D0000 0x010000;kernel raw 0x1E0000 0x800000
dfu_alt_info_ram=kernel ram 0x80200000 0x4000000;fdt ram 0x80f80000 0x80000;ramdisk ram 0x81000000 0x4000000
dfu_bufsiz=0x10000
dofastboot=0
emmc_android_boot=setenv eval_bootargs setenv bootargs $bootargs; run eval_bootargs; setenv mmcdev 1; setenv fdt_part 3; setenv boot_part 9; if test $reboot_image = recovery; then setenv boot_part 8; setenv reboot_image boot; saveenv; fi;setenv machid fe6; mmc dev $mmcdev; mmc rescan; part start mmc ${mmcdev} ${fdt_part} fdt_start; part size mmc ${mmcdev} ${fdt_part} fdt_size; part start mmc ${mmcdev} ${boot_part} boot_start; part size mmc ${mmcdev} ${boot_part} boot_size; mmc read ${fdtaddr} ${fdt_start} ${fdt_size}; mmc read ${loadaddr} ${boot_start} ${boot_size}; echo Booting from eMMC ...; bootm $loadaddr $loadaddr $fdtaddr;
envboot=mmc dev ${mmcdev}; if mmc rescan; then echo SD/MMC found on device ${mmcdev};if run loadbootscript; then run bootscript;else if run loadbootenv; then echo Loaded env from ${bootenvfile};run importbootenv;fi;if test -n $uenvcmd; then echo Running uenvcmd ...;run uenvcmd;fi;fi;fi;
ethaddr=0c:b2:b7:f6:ff:bc
fastboot.board_rev=H.0
fastboot.cpu=J6
fastboot.secure=GP
fastboot.userdata_size=unknown
fdt_addr_r=0x88000000
fdtaddr=0x88000000
fdtcontroladdr=fdf0a598
fdtfile=undefined
findfdt=if test $board_name = omap5_uevm; then setenv fdtfile omap5-uevm.dtb; fi; if test $board_name = dra7xx; then setenv fdtfile dra7-evm.dtb; fi;if test $board_name = dra72x-revc; then setenv fdtfile dra72-evm-revc.dtb; fi;if test $board_name = dra72x; then setenv fdtfile dra72-evm.dtb; fi;if test $board_name = dra71x; then setenv fdtfile dra71-evm.dtb; fi;if test $board_name = dra76x; then setenv fdtfile dra76-evm.dtb; fi;if test $board_name = beagle_x15; then setenv fdtfile am57xx-beagle-x15.dtb; fi;if test $board_name = beagle_x15_revb1; then setenv fdtfile am57xx-beagle-x15-revb1.dtb; fi;if test $board_name = am57xx_evm; then setenv fdtfile am57xx-evm.dtb; fi;if test $board_name = am57xx_evm_reva3; then setenv fdtfile am57xx-evm-reva3.dtb; fi;if test $board_name = am572x_idk && test $idk_lcd = no; then setenv fdtfile am572x-idk.dtb; fi;if test $board_name = am572x_idk && test $idk_lcd = osd101t2045; then setenv fdtfile am572x-idk-lcd-osd.dtb; fi;if test $board_name = am572x_idk && test $idk_lcd = osd101t2587; then setenv fdtfile am572x-idk-lcd-osd101t2587.dtb; fi;if test $board_name = am571x_idk && test $idk_lcd = no; then setenv fdtfile am571x-idk.dtb; fi;if test $board_name = am571x_idk && test $idk_lcd = osd101t2045; then setenv fdtfile am571x-idk-lcd-osd.dtb; fi;if test $board_name = am571x_idk && test $idk_lcd = osd101t2587; then setenv fdtfile am571x-idk-lcd-osd101t2587.dtb; fi;if test $fdtfile = undefined; then echo WARNING: Could not determine device tree to use; fi;
finduuid=part uuid mmc ${bootpart} uuid
fit_bootfile=fitImage.itb
fit_loadaddr=0x88000000
importbootenv=echo Importing environment from mmc${mmcdev} ...; env import -t ${loadaddr} ${filesize}
kernel_addr_r=0x82000000
loadaddr=0x82000000
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}
loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr
loadfdt=load ${devtype} ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}
loadfit=run args_fit; bootm ${loadaddr}#${fdtfile};
loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}
mmcboot=if mmc dev ${mmcdev}; then setenv devtype mmc; if mmc rescan; then echo SD/MMC found on device ${mmcdev};if run loadimage; then run loadfdt; echo Booting from mmc${mmcdev} ...; run args_mmc; bootz ${loadaddr} - ${fdtaddr}; fi; fi; fi;
mmcdev=0
mmcloados=run args_mmc; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if run loadfdt; then bootz ${loadaddr} - ${fdtaddr}; else if test ${boot_fdt} = try; then bootz; else echo WARN: Cannot load the DT; fi; fi; else bootz; fi;
mmcrootfstype=ext4 rootwait
netargs=setenv bootargs console=${console} ${optargs} root=/dev/nfs nfsroot=${serverip}:${rootpath},${nfsopts} rw ip=dhcp
netboot=echo Booting from network ...; setenv autoload no; dhcp; run netloadimage; run netloadfdt; run netargs; bootz ${loadaddr} - ${fdtaddr}
netloadfdt=tftp ${fdtaddr} ${fdtfile}
netloadimage=tftp ${loadaddr} ${bootfile}
nfsopts=nolock
partitions=uuid_disk=${uuid_gpt_disk};name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}
partitions_android=uuid_disk=${uuid_gpt_disk};name=xloader,start=128K,size=256K,uuid=${uuid_gpt_xloader};name=bootloader,size=2304K,uuid=${uuid_gpt_bootloader};name=environment,size=256K,uuid=${uuid_gpt_environment};name=misc,size=128K,uuid=${uuid_gpt_misc};name=reserved,size=384K,uuid=${uuid_gpt_reserved};name=efs,size=16M,uuid=${uuid_gpt_efs};name=crypto,size=16K,uuid=${uuid_gpt_crypto};name=recovery,size=10M,uuid=${uuid_gpt_recovery};name=boot,size=10M,uuid=${uuid_gpt_boot};name=system,size=768M,uuid=${uuid_gpt_system};name=vendor,size=256M,uuid=${uuid_gpt_vendor};name=cache,size=256M,uuid=${uuid_gpt_cache};name=ipu1,size=8M,uuid=${uuid_gpt_ipu1};name=ipu2,size=8M,uuid=${uuid_gpt_ipu2};name=dsp1,size=8M,uuid=${uuid_gpt_dsp1};name=dsp2,size=8M,uuid=${uuid_gpt_dsp2};name=userdata,size=-,uuid=${uuid_gpt_userdata}
pxefile_addr_r=0x80100000
ramdisk_addr_r=0x88080000
rdaddr=0x88080000
reboot_image=boot
rootpath=/export/rootfs
scriptaddr=0x80000000
scsidevs=0
serial#=0400d00f147400e2
soc=omap5
static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off
stderr=serial@4806a000
stdin=serial@4806a000
stdout=serial@4806a000
update_to_fit=setenv loadaddr ${fit_loadaddr}; setenv bootfile ${fit_bootfile}
usbtty=cdc_acm
vendor=ti
ver=U-Boot 2016.05-00008-g1fbee98-dirty (Jun 06 2019 - 20:35:16 +0800)
vram=16M

Environment size: 7479/131067 bytes
=>

That's all what i have done.

I want to know what can i do next to make eMMC flashed successful over DFU tools?

Regards,

Liu Gan


AM5728: Beagleboard-X15 reference design

Linux/DRA80M: Error while building Linux Kernel

66AK2H14: DDR and cacheability attribute

$
0
0

Part Number:66AK2H14

Hello

 

I have a question for my understanding of how the DDR (or DDR memory controller) works.

 

Let’s say that we have a keystone I or keystone II processor.

Let’s suppose we use L2 memory as RAM and not cache.

 

For these architectures from my understanding and tests,

The cache (L1D) is of type “write around”

Which to me means that :

-          If an address is not in the cache, the data is written to the address and not in the cache.

-          A subsequent read at that address would cause a “cache miss” (the data is not in the cache), and the data will be fetched from physical memory

 

Q1) is this understanding correct ?

 

Then let’s move to two use cases :

a)

-          I have disabled cacheability in the DDR address range (through MAR registers)

-          I never read data in DDR, I only write data

-          I measure speed performances : they are low, a couple hundreds of MB/s

 

b)

-          I have enabled cacheability in the DDR address range (through MAR registers)

-          I never read data in DDR, I make sure the DDR address range is not in cache, I only write data to the DDR address range

-          I measure speed performances : they are much better, with several thousand of MB/s

 

In b) as no data is in the cache and because the cache is of type “write around”, I write directly in DDR memory. So the cache is not used. However performances are very different.

 

Q2) how do you explain such a big difference in performances ?

 

Thank you

Regards

Clement

RTOS/OMAP-L138: GPIO interrupt issue

$
0
0

Part Number:OMAP-L138

Tool/software: TI-RTOS

Hello,

I use pdk 1_0_6 and I know GPIO_LedBlink exmaple but I have problem with GPIO interrupt when I should use more then 1 input pin to interrupt:

/* XDCtools Header files */
#include <xdc/std.h>
#include <xdc/cfg/global.h>
#include <xdc/runtime/System.h>
#include <stdio.h>

#include <ti/board/board.h>
#include <ti/drv/gpio/GPIO.h>
#include <ti/drv/gpio/soc/GPIO_soc.h>

#include "usm_gpio.h"

/**********************************************************************
 ************************** GPIO  *************************************
 **********************************************************************/
/* GPIO Driver board specific pin configuration structure */
GPIO_PinConfig gpioPinConfigs[] =
{
    //MMCSD
    GPIO_DEVICE_CONFIG(GPIO_MMC_SDCD_PORT_NUM, GPIO_MMC_SDCD_PIN_NUM) | GPIO_CFG_IN_INT_BOTH_EDGES | GPIO_CFG_INPUT,
    //BUZZER
    GPIO_DEVICE_CONFIG(GPIO_PORT_NUM0, GPIO_BUZZER_PIN_NUM) | GPIO_CFG_IN_INT_NONE | GPIO_CFG_OUTPUT,
    //LED_ARRX
    GPIO_DEVICE_CONFIG(GPIO_PORT_NUM0, GPIO_LED_EXT0_PIN_NUM) | GPIO_CFG_IN_INT_NONE | GPIO_CFG_OUTPUT,
    GPIO_DEVICE_CONFIG(GPIO_PORT_NUM0, GPIO_LED_EXT1_PIN_NUM) | GPIO_CFG_IN_INT_NONE | GPIO_CFG_OUTPUT,
    GPIO_DEVICE_CONFIG(GPIO_PORT_NUM0, GPIO_LED_EXT2_PIN_NUM) | GPIO_CFG_IN_INT_NONE | GPIO_CFG_OUTPUT,
    GPIO_DEVICE_CONFIG(GPIO_PORT_NUM0, GPIO_LED_EXT4_PIN_NUM) | GPIO_CFG_IN_INT_NONE | GPIO_CFG_OUTPUT,
    GPIO_DEVICE_CONFIG(GPIO_PORT_NUM0, GPIO_LED_EXT5_PIN_NUM) | GPIO_CFG_IN_INT_NONE | GPIO_CFG_OUTPUT,
    //S4 ->SW1-SW6
    GPIO_DEVICE_CONFIG(GPIO_PORT_NUM0, GPIO_S4_SW1_PIN_NUM) | GPIO_CFG_IN_INT_NONE | GPIO_CFG_INPUT,
    GPIO_DEVICE_CONFIG(GPIO_PORT_NUM0, GPIO_S4_SW2_PIN_NUM) | GPIO_CFG_IN_INT_NONE | GPIO_CFG_INPUT,
    GPIO_DEVICE_CONFIG(GPIO_PORT_NUM0, GPIO_S4_SW3_PIN_NUM) | GPIO_CFG_IN_INT_NONE | GPIO_CFG_INPUT,
    GPIO_DEVICE_CONFIG(GPIO_PORT_NUM0, GPIO_S4_SW4_PIN_NUM) | GPIO_CFG_IN_INT_NONE | GPIO_CFG_INPUT,
    GPIO_DEVICE_CONFIG(GPIO_PORT_NUM0, GPIO_S4_SW5_PIN_NUM) | GPIO_CFG_IN_INT_NONE | GPIO_CFG_INPUT,
    GPIO_DEVICE_CONFIG(GPIO_PORT_NUM0, GPIO_S4_SW6_PIN_NUM) | GPIO_CFG_IN_INT_NONE | GPIO_CFG_INPUT,
};

/* GPIO Driver call back functions */
GPIO_CallbackFxn gpioCallbackFunctions[] =
{
    //MMCSD
    AppGpioCallbackFxn,
    //BUZZER
    NULL,
    //LED_ARRX
    NULL,
    NULL,
    NULL,
    NULL,
    NULL,
    //S4 ->SW1-SW6
    AppGpioCallbackFxn2,
    NULL,
    NULL,
    NULL,
    NULL,
    NULL,
};

GPIO_v0_Config GPIO_v0_config =
{
    gpioPinConfigs,
    gpioCallbackFunctions,
    sizeof(gpioPinConfigs) / sizeof(GPIO_PinConfig),
    sizeof(gpioCallbackFunctions) / sizeof(GPIO_CallbackFxn),
    0,
};

void usm_board_initGPIO(void)
{

    GPIO_v0_HwAttrs gpio_cfg;
    /* Get the default SPI init configurations */
    GPIO_socGetInitCfg(GPIO_MMC_SDCD_PORT_NUM, &gpio_cfg);
    /* Modify the default GPIO configurations if necessary */
    //***/
    /* Set the default GPIO init configurations */
    GPIO_socSetInitCfg(GPIO_MMC_SDCD_PORT_NUM, &gpio_cfg);
    /* Setup GPIO interrupt configurations */
    GPIO_socSetBankInt(GPIO_MMC_SDCD_PORT_NUM, GPIO_MMC_SDCD_PIN_NUM, NULL);
    GPIO_socSetBankInt(GPIO_MMC_SDCD_PORT_NUM, GPIO_S4_SW2_PIN_NUM, NULL);

    /* GPIO initialization */
    GPIO_init();
    /* Enable GPIO interrupt on the specific gpio pin */
    GPIO_enableInt(GPIO_PIN_MMC_SDCD);
    GPIO_enableInt(GPIO_PIN_S4_SW2);

}

AppGpioCallbackFxn and AppGpioCallbackFxn2 I have in other file but intterupt form GPIO_PIN_MMC_SDCD is correct but GPIO_PIN_S4_SW2 not interrupt...
When I changed the order in gpioPinConfigs this works correctly GPIO_PIN_S4_SW2 abut not GPIO_PIN_MMC_SDCD ...

When I checked in GPIO Interrupt Status the interrupt status is 1.
Where is the problem?

Best regards,
Patryk

AM5728: AM5728 HW decoder

$
0
0

Part Number:AM5728

From customer

A stream data has been decoded by MPEG2 HW decoder (ducatimpeg2dec) and they have faced an error.

The attached is the log file.

 It should be caused by a stream data, a field encoder, GStreamer is utilized, etc.

 On the other hand the software decode by GStreamer (avdec_mpeg2video) works OK.

However, the performance is insufficient so customer(Please visit the site to view this file) would like to use HW decoder but they faced error.

 

If the stream data is necessary, please let us know so that we could consider to share it with you somehow.

RTOS/AM5728: SW Development for 4ch Switch on PRU-ICSS

$
0
0

Part Number:AM5728

Tool/software: TI-RTOS

Hi,

I understood it from the below thread that the current PRU supports 2 port only switch. It's feasible to have 4 port switch with new firmware, essentially doing a 4 port switch would require a shared common FDB to prevent flooding to all ports.
https://e2e.ti.com/support/processors/f/791/p/807234/2991287#2991287

If user tries to develop SW for 4 port switch using two PRU-ICSS, is it OK to create only Arm code with 2 port switch PRU firmware ? or PRU firmware must be modified ?

Thanks and regards,
Hideaki

Linux/AM5726: Configuring interrupt priorities

$
0
0

Part Number:AM5726

Tool/software: Linux

Hi,

We have several gpios that we use to trigger interrupts. Is there a way to tweak the priority of these interrupts so that one gpio pin would have higher priority than another gpio pin.

We are using RT Linux.

Thanks, 

David


Linux/AM5728: USB documentation

$
0
0

Part Number:AM5728

Tool/software: Linux

Hi TI,

We would like to modify and debug the Sitara Linux USB device driver and noticed the reference manual indicates (section 24.7, pg 6171) we should contact our sales representative on how to obtain the documentation under NDA.  Our local Arrow representative sent us to the TI forum for support.  Do you have contact information available to discuss the NDA process?

Best Regards,

Jason 

RTOS/AM3359: McSPI control form PRU

$
0
0

Part Number:AM3359

Tool/software: TI-RTOS

Hi,

I want to use the PRU to control MCSPI0. I set clk, cs, d0, d1 all in 0x30 (rxactive, pullup) in device tree. In register cm_per_spi0_clkctrl (0x44e00004c) i wrote 0x2. Write 0 in PRU-ICSS CFG to ensure ocp master port is enabled.

I set some spi parameters, then open the channel, set CS to LOW, write data in TX.

I checked register mcspi_ch0stat, i can see, EOT is 1, TXS is 1, RXS is 1. I think this represents a successful SPI transfer. However, the 8-bit clk is not displayed on the oscilloscope. I tried disabling the SPI node in the device tree to ensure that linux does not control the SPI, but there is still no signal display.

My question is:

1. do I need some special settings when using SPI in a PRU? For example, CM_PER_L4LS_CLKSTCTRL or M_PER_L3S_CLKSTCTRL. Because I saw mcspi.c in Starterware, this example has bit0 and 1. set these registers.
2. I did not map the mcpsi interrupt to the pru interrupt, does this affect the clock output. I just want to complete a simple function: write the data in tx, and then transfer it to the slave.

I used the 05_03_00_07 RTOS_SDK in BBB

RTOS/TDA3XEVM: TDA3xx - UART issue RX

$
0
0

Part Number:TDA3XEVM

Tool/software: TI-RTOS

Hi,

I try to write an UART driver for a custom board but I have some problems to configure the UART - Registers. TX works fine.

I use the UART3 via GPIO4_15 (PAD F14) (RX) and GPIO4_16 (Pad C14) (TX).

I tryed different configurations but I didnt get any Data via RX. It seems that the software flow control is activated is that true (UART3_UART_EFR)?
We like to use the UART in interrupt mode without any flow control.

Register Dump after Configuration:

R UART3_UART_DLL 0x0000000B 0x0000003C
R UART3_UART_RHR 0x0000000B 0x0000003C
R UART3_UART_THR 0x0000000B 0x0000003C
R UART3_UART_DLH 0x0000000B 0x00000000
R UART3_UART_IER 0x0000000B 0x00000000
R UART3_UART_EFR 0x0000000B 0x000000C1
R UART3_UART_FCR 0x0000000B 0x000000C1
R UART3_UART_IIR 0x0000000B 0x000000C1
R UART3_UART_LCR 0x0000000B 0x00000003
R UART3_UART_MCR 0x0000000B 0x00000040
R UART3_UART_XON1_ADDR1 0x0000000B 0x00000040
R UART3_UART_LSR 0x0000000B 0x00000060
R UART3_UART_XON2_ADDR2 0x0000000B 0x00000060
R UART3_UART_MSR 0x0000000B 0x00000011
R UART3_UART_TCR 0x0000000B 0x00000011
R UART3_UART_XOFF1 0x0000000B 0x00000011
R UART3_UART_SPR 0x0000000B 0x0000002E
R UART3_UART_TLR 0x0000000B 0x0000002E
R UART3_UART_XOFF2 0x0000000B 0x0000002E
R UART3_UART_MDR1 0x0000000B 0x00000000
R UART3_UART_UASR 0x0000000B 0x00000040
R UART3_UART_SCR 0x0000000B 0x000000C1
R UART3_UART_SSR 0x0000000B 0x00000004
R UART3_UART_MVR 0x0000000B 0x50410604
R UART3_UART_SYSC 0x0000000B 0x00000000
R UART3_UART_SYSS 0x0000000B 0x00000001
R UART3_UART_WER 0x0000000B 0x000000FF
R UART3_UART_RXFIFO_LVL 0x0000000B 0x00000000
R UART3_UART_TXFIFO_LVL 0x0000000B 0x00000000
R UART3_UART_IER2 0x0000000B 0x00000000
R UART3_UART_ISR2 0x0000000B 0x00000003
R UART3_UART_FREQ_SEL 0x0000000B 0x0000001A
R UART3_UART_MDR3 0x0000000B 0x00000000
R UART3_UART_TX_DMA_THRESHOLD 0x0000000B 0x00000000

Can you please help me?

Best regards

Alex

RE: Build error with DSPLIB assembly with CGT 7.4.x

$
0
0

Hi Sahin,

Thank you for uploading DSPLIB.

By the way, however, my customer tried rebuilding the C67x DSPLIB
by following the instruction written in "TMS320C67x DSP Library
Programmer’s Reference Guide(spru657b)".

But rebuilding failed by showing following error:
*************************************************
"DSPF_sp_vecmul.asm", ERROR!   at line 214: [E0801] Too many cross-path reads
                                                    (2) from register B0
               ADD    .L2X    4,          A3,      B7     ; set store cntr
     ||[!B2]SUB .S1X    B0,     1,        A2 ; set load cntr
     ||[ B2]ADD .S2     B0,     1,        B0  ; adjust cntr
     ||[B2]MV           B0,     A2           ; set load cntr
     ||     LDDW   .D2T2   *B6++,     B5:B4         ; load y1:y0
*************************************************

I tried by using C6000 CGT v7.3.23 but it failed with same error.

Do you think this is a bug of DSPLIB? Or is it because using newer compiler than than DSPLIB released?
Do you know any workaroud for this error?

best regards,
g.f.

Linux/AM5718: Persistent USB transfer error after waking from sleep

$
0
0

Part Number:AM5718

Tool/software: Linux

In our design (derived from but now significantly different than that of the AM5728 EVM), we have USB2 configured as a host talking to a WiFi radio which enumerates as a CDC ECM class device.  As long as we don't put the processor to sleep, there are no issues.  If we do go through a sleep/wake cycle, there are no detectable surface issues.  Radio communications seemingly proceed just as they did before the sleep/wake cycle.  However while chasing another issue, I'd enabled additional dynamic debug and discovered that after the sleep/wake cycle, there are repeated (every 96 ms) transfer errors.  Again, note that these errors don't seem to affect the ability to communicate with the radio.  Their biggest impact that we've been able to detect is wasted CPU cycles.

Doing

echo "module usbnet +p" > /sys/kernel/debug/dynamic_debug/control

I see the following repeated constantly and forever after a sleep/wake cycle

cdc_ether 1-1:1.0 eth0: intr status -71

The '-71' translates to EPROTO.  If I further do

echo "module xhci_hcd +p" > /sys/kernel/debug/dynamic_debug/control

additional accompanying messages reveal that the reason for the protocol status report is

xhci-hcd xhci-hcd.0.auto: Transfer error on endpoint

which comes from handle_tx_event() in drivers/usb/host/xhci-ring.c.

I do see additional messages that show the code trying to recover from this, however the work is clearly ineffective as 96 ms later, the same thing happens again.

At this point, I run into a dead end as the Technical Reference Manual (SPRUHZ7H) does not have any information whatsoever on USB errors.  In fact, the TRM explicitly states that there is insufficient information to design (and therefore) debug a Linux driver and that I must contact my sales rep to be able to obtain that documentation under an NDA.  That is being pursued but will obviously take time.  In the meantime, I thought I'd post the symptoms to see if this is a know issue.

Viewing all 17527 articles
Browse latest View live


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