Activity
From 08/24/2013 to 09/22/2013
09/20/2013
- Hej,
I'm new to the TI OMAP and previously worked with AD Sharc-Processors.
For a new product I switched to the MityDSP L138F. Basic system requirements are audio input (TDM, 16 or 32 channels) using the McBSP, audio processing on ...
09/19/2013
- MW 05:33 PM Software Development: RE: DSP DMA crashes Linux
- Hi Lars,
This is interesting... I did not think that the linux code was using the Quick DMA PaRAMS. I know you had to do this if you were planning to use dedicated PaRAMs for peripheral blocks, but not for the Quick DMAs. Sorry that... - LM 05:09 PM Software Development: RE: DSP DMA crashes Linux
- Dave,
I think I found the problem.
When comparing the board definition file for the da850 evm (board-da850-evm.c) and the mityomapl138 (board-mityomapl138.c), I realized that the latter file did not reserve any dma resources. (It sim... - DR 04:17 PM Software Development: RE: DSP DMA crashes Linux
- I will have to give that some thought. It was my understanding that the two processor each had use of a different part of the DMA engine, and so they shouldn't conflict. I wonder if somewhere along the way that rule has changed. I'll ...
- LM 02:54 PM Software Development: RE: DSP DMA crashes Linux
- Hi Dave,
I have done a full matrix of experiments, interrupt 7 or 8, with and without MMC in the kernel, and booting off the internal flash or MMC.
Both interrupt 7 and 8 give the same results.
My test program works fine with MMC supp... - SH 03:54 PM Software Development: RE: SYS/BIOS and SYSLINK
- It seems to me that TI is moving to SYS/BIOS and DSP/BIOS will soon be deprecated. Most of the really useful training stuff is for SYS/BIOS, and instrumentation support for DSP/BIOS is under "Legacy" - that tells me something. That is ...
09/18/2013
- MW 09:20 PM Software Development: RE: SYS/BIOS and SYSLINK
- Don't have any immediate plans to update, though they should compile against SYS/BIOS without much modification.
What do you mean by "CCS do not support DSP/BIOS very well"? What feature in DSP/BIOS is not supported? - LM 05:48 PM Software Development: RE: DSP DMA crashes Linux
- Dave,
I have confirmed that if I run Linux off the built in flash disk (and disable MMC support) I can do DMA transfers on the DSP without causing any issues with Linux.
There definitely seems to be a conflict between how Linux allocat... - DR 05:46 PM Software Development: RE: DSP DMA crashes Linux
- Hi Lars,
I am currently working on a project that uses the QDMA class to move data between the FPGA and memory, and it has the MMC support compiled in, so I don't think that is it. You can try it, but I'd be surprised.
You could ... - LM 02:19 PM Software Development: RE: DSP DMA crashes Linux
- Thanks Dave,
That was a lot of useful information!
I did indeed pull in some off the mark libraries during link time.
So I cleaned up my project, making sure to use the EDMA3 libraries from from the MDK instead of the copy installed o... - DR 01:08 PM Software Development: RE: DSP DMA crashes Linux
- I assume you are not actually using any .c files from the EDMA code? If so, get rid of those. All you need from the EDMA installation is the library files. Specifically, make sure you have this in your Search Path (under project Build...
- LM 12:37 PM Software Development: RE: DSP DMA crashes Linux
- Hi Dave,
Thanks for the reply.
I tried that - still the same problem.
My sense is that this has something to do with how DMA gets configured. The comments in the DspQDMA.cpp code mention (in a comment)
"// EDMA3 features specific... - DR 11:26 AM Software Development: RE: DSP DMA crashes Linux
- Hi Lars,
The tcDspQDMA class handles all of the setup for the dma, so you don't need the HWI_eventMap() call. That may be your only mistake. Try your code without that.
Dave
09/17/2013
- MW 12:35 PM FPGA Development: RE: BUSY and AWAKE LEDs
- D2 (AWAKE) is connected to pin P15 of the FPGA. Drive high to light.
D3 (BUSY) is connected to pin P16 of the FPGA. Drive high to light.
-Mike
- On my L138-DI-225-RI board, I observe two LEDs labeled "BUSY" and "AWAKE". These are located next to the "DONE" LED which is obviously connected to the DONE pin of the FPGA. Are the other two LEDs connected to the FPGA? If so, what pi...
- Hi,
I ran into a basic problem testing out DMA transfers on the DSP to see if the speed improvement is worth the effort.
The program is a variation on the HelloDsp code and I added a couple of buffers, cleared them and attempted a tra...
09/16/2013
- Are there plans to update the libraries and examples (e.g. DSPHelloWorld) to SYS/BIOS and SYSLINK? TI seems to be in the process of deprecating DSP/BIOS and DSPLink, and the newer versions of CCS do not support DSP/BIOS very well.
- SH 12:45 PM Software Development: RE: Debugging in CCSv5 using GDB
- Thanks for your reply - I have put this issue on the back burner as I am now working on DSP side software for a while...but I will get back to it.
- RK 04:50 AM Software Development: RE: DSP EDMA Semaphore problem
- Sorry about the problem. The cause of this was the incorrect memory access of mine. I basically tried to simultaneously operate on the same memory addresses both by the app and the EDMA (which did not end the transfer). Now that I have d...
09/15/2013
- SH 09:39 PM Software Development: RE: DSP GPIO interrupts (No-FPGA)
- I have some follow-on questions for this thread, because this is something I am working on right now (DSP/BIOS non-FPGA GPIO interrupts. My questions are:
1. re pinmux - according to the Industrial I/O schematic, it appears that many...
09/12/2013
- Hello,
I have succesfully transferred the blocks of data using the BlockTransfer Method from DspQDMA.cpp (see thread: http://support.criticallink.com/redmine/boards/10/topics/3027). However, I am now attempting to synchronize the comple...
09/11/2013
- BD 07:25 PM Software Development: RE: Debugging in CCSv5 using GDB
- Steve,
I have been unable to reproduce the issue and the obvious parts of your python environment seem to be configured correctly.
My understanding is that the pydebug error occurs when the tool is using the wrong version of pytho... - SH 05:58 PM Software Development: RE: Debugging in CCSv5 using GDB
- I would appreciate some help with this - I have no idea how to solve this problem. Without GDB working I have no way to debug my application running on top of linux.
09/10/2013
- DG 10:25 PM Software Development: RE: Linux blocks DSP-core access to EMIFA
- Hello!
I have found a root of the problem - EMIFA goes to Disable state during kernel booting. Previously I have being reading EMIFA MDSTAT3 reg, BUT I made a mistake and used wrong offset for the register's address, though I read ano... - DG 09:57 AM Software Development: RE: Linux blocks DSP-core access to EMIFA
- Mike, yes, I do like that and observe both - memory window and regs tab in CCS and my test program does an output via UART. CCS shows 0's after kernel is being booting but my program returns another value, different from 0 but not 0x4000...
- MW 09:02 AM Software Development: RE: Linux blocks DSP-core access to EMIFA
- Hmmm.
The MIDR is read only, it cannot be changed by any software. I haven't seen behavior like this before.
Are you reading this value using the JTAG debugger and code composer studio? How are you reading the value? It is possi... - DG 07:59 AM Software Development: RE: Linux blocks DSP-core access to EMIFA
- Michael, I have simplified the setup: as I wrote, now DSP-core reads just several registers and EMIFA_MIDR_REG which holds constant returns wrong value after kernel booting, but others are correct. So my problem is not related to FPGA. A...
- MW 07:41 AM Software Development: RE: Linux blocks DSP-core access to EMIFA
- u-Boot is the only software (as opposed to the kernel) that should be modifying the EMIFA registers if you are using 2.6.34 from Critical Link.
The EMIFA registers are not cached. The SYSCFG registers may be modified by the kernel wh... - DG 06:52 AM Software Development: RE: Linux blocks DSP-core access to EMIFA
- Could it be related to caching?
- DG 06:13 AM Software Development: RE: Linux blocks DSP-core access to EMIFA
- I wrote that kernel resets EMIFA setups - I mean CCS debug starts to show 0's for EMIFA registers and for other peripherals' registers as well. I setup a test code - some registers periodical reading (SYSCFG0_REVID_REG, SYSCFG0_DEVIDR0_R...
- DG 03:55 AM Software Development: RE: Linux blocks DSP-core access to EMIFA
- Does anybody use DSP-EMIFA-FPGA communication with DSP using no OS?
09/09/2013
- DG 07:28 AM Software Development: RE: Linux blocks DSP-core access to EMIFA
- 2.6.34
- MW 07:12 AM Software Development: RE: Linux blocks DSP-core access to EMIFA
- What version of the kernel are you using?
- DG 05:50 AM Software Development: RE: Linux blocks DSP-core access to EMIFA
- Ok, I see the reason - kernel booting resets EMIFA setups. Is there any way to prevent it than?
- Hello!
DSP-core reads memory mapped FPGA register by EMIFA. When ARM-core runs UBOOT everything works fine. When Linux kernel booting starts, at some point EMIFA transactions become blocked (I observe it with oscilloscope, there is no...
09/06/2013
- SH 07:32 PM Software Development: RE: SIGNAL issues with DSPLink
- I was able to make the alarm work by modifying CFG_linux.c and rebuilding DSPLink. I tried two methods:
1. turn off signal handling altogether.
2. remove SIGALRM from the list of signals handled by DSPLink.
Either of these methods ... - I am trying to use the alarm() function in an application much like DSPHelloWorld. But if you add an alarm the application will crash when it enters the alarm handler. You can reproduce the behaviour very simply by adding an alarm to DSP...
- SH 12:18 PM Software Development: RE: Debugging in CCSv5 using GDB
- 'which python' returns the version that is in /usr/local/oecore-i686...
But if I run 'arm-angstrom-linux-gnueabi-gdb' I get the same result as I detailed above... ending in '...no attribute 'pydebug'' - BD 11:29 AM Software Development: RE: Debugging in CCSv5 using GDB
- Steven,
That looks good, I accidentally included "python" in the directory name. You have confirmed the python executables are there.
When you run this command what do you get? - JC 10:01 AM Software Development: RE: Shutdown misbehaving
- Helmut,
As long as your application doesn't need to do any cleanup (saving files), the kill -9 should be ok.
If you want to try to diagnosis it quickly, i've had good luck using valgrind memory analyzer. This was easiest if you ... - MW 10:00 AM Software Development: RE: Shutdown misbehaving
- My guess is that the DSPLINK driver library is catching the signals and shutting itself down (a default behavior to support cleaning up programs terminated by CTRL-C), most likely prior to your app/dsp shutting down nicely, so there is a...
- HF 09:57 AM Software Development: RE: Shutdown misbehaving
- Probably RESOLVED.
There was another bug I thought unrelated, where I was calling system("poweroff.sh") multiple times. When I fixed this bug, the shutdown followed by power supply kill worked once. So it seems that the triple run o... - Under Angstom linux on a mityomap L138F, I've created /etc/rc0.d/S99poweroffAPP.sh, a symbolic link of /etc/init.d/poweroffAPP.sh, which in turn echos recognizable "KILL POWER SUPPLY" text and then outputs to a GPIO pin and causes my pow...
09/05/2013
- SH 07:59 PM Software Development: RE: Debugging in CCSv5 using GDB
- I don't have a python directory in the /usr/local/oecore-i686/sysroots/i686-angstromsdk-linux/usr/bin directory, but there are python executables there: 'python' and 'python2.7'.
The PATH variable already included the path to /usr/loc... - BD 06:12 PM Software Development: RE: Debugging in CCSv5 using GDB
- Steven,
It looks like it's trying to use the distribution's python (which likely doesn't have the pydebug package).
Please verify you have a python executable at:
/usr/local/oecore-i686/sysroots/i686-angstromsdk-linux/usr/bin/pyth... - SH 05:26 PM Software Development: RE: Debugging in CCSv5 using GDB
- I followed the steps in the 'VM Build Steps" part of the Linux Build Virtual Machine tutorial - except that I installed 12.04LTS instead of 10.04LTS.
- SH 05:18 PM Software Development: RE: Debugging in CCSv5 using GDB
- I am running with a Ubuntu Linux distribution - 12.04LTS in VirtualBox Manager.
More information - 'gdb' run from the terminal connects to my running application (but not usefully I think), but running 'arm-angstrom-linux-gnueabi-gdb'... - BD 04:57 PM Software Development: RE: Debugging in CCSv5 using GDB
- Hello Steven,
Are you running CCSv5 from a Critical Link Virtual Machine image or from your own Linux distribution (or on Windows)?
-Bob
- SH 03:33 PM Software Development: RE: Debugging in CCSv5 using GDB
- More information - I discovered that I was using the default gdb, so changed that to the 'usr/local/oecore-i686/sysroots/i686-angstromsdk-linux/usr/bin/armv5te-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gdb' version of gfb. I hav...
I am using CCSv5 to create projects using the Critical Link toolchain. This is working fine - DSPHelloWorld etc run on the target with no issues. Now I would like to use GDB to debug remotely runninf gdbserver on the target. Ihave c...
09/04/2013
- JC 02:27 PM Software Development: RE: Graceful shutdown at what level?
- I'm not aware of any specific process monitoring programs that we use. I know that system-D has the ability to do it but we haven't switched over to that on the am335x boards and its probably more work than your looking for. The simple...
- HF 12:10 PM Software Development: RE: Graceful shutdown at what level?
- CORRECTION: Notes should do symbolic link copy: file /etc/rc0.d/S99hgfshutdown created via "cd /etc/rc0.d" and "cp -s ../init.d/hgfshutdown99.sh S99hgfshutdown"
- HF 12:01 PM Software Development: RE: Graceful shutdown at what level?
- Jonathan,
In fact I just got that half working a moment before seeing your post, and completely working now. I put notes below for others.
*QUESTION: Now I would like to make my application a daemon, so that it will reload if it c... - JC 10:47 AM Software Development: RE: Graceful shutdown at what level?
- Helmut,
You could try adding the KILL voltage script to /etc/rc0.d. If you look there you can see that the filesystem is umounted around S60 so if you put your script after that say S80KillPower then it would run after most of the sh... - HF 10:35 AM Software Development: RE: Graceful shutdown at what level?
- Michael & Tim:
I sincerely appreciate your advice and want to follow through as best that I can. While I am ultimately experienced at microelectronics and embedded programming, my linux expertise is limited mostly to regular user use...
09/03/2013
- TI 06:14 PM Software Development: RE: Graceful shutdown at what level?
- Helmut
I would think you could use the linux power management features to do this. Much like you can push a button on your laptop or PC to have it turn off.
See https://wiki.archlinux.org/index.php/Power_Management for an example. You ... - MW 06:03 PM Software Development: RE: Graceful shutdown at what level?
- Well,
Some questions come to mind as you have a couple of isses.
- Is your application writing anything to the filesystem (assuming a NAND based implementation) and what filesystem are you using (JFFS2)? If it's not writing anyt... - I've inherited someone else's hardware design, based on the Critical Link OMAP-L138F SoM, and I must finish up the software.
I need to code graceful shutdown based on a pushbutton controller and battery voltage monitor. I see three p... - SH 02:04 PM Software Development: RE: Programming fpga from inside ARM application
- Thanks, Mike. I am running linux, and the system() call was just what I was looking for.
09/02/2013
- MW 08:36 AM Software Development: RE: Programming fpga from inside ARM application
- Is the ARM an linux application or a bare metal application?
If it is a linux application, you will need to write a custom driver (if our driver isn't good enough to suit your needs) as you need direct access to the EMIFA bus and GPIO...
08/30/2013
- We have examples of how to program the FPGA from uboot or from the linux command prompt. I have used both methods successfully. However, for various reasons I would like to load the image file into the FPGA from a running application ...
- CR 11:15 AM Software Development: RE: OMAPL138 DSP-EDMA3 transfer from EMIFA when Linux is running on ARM
- Another update...
Now Ti reports that I have to say the linuxkernel to reserve the DMA-channels what I using on the dsp. In my case channel 26 on CC1. I did this by getting out the following code from the "board-da850-evm.c" and put i... - CR 08:20 AM Software Development: RE: OMAPL138 DSP-EDMA3 transfer from EMIFA when Linux is running on ARM
- I got an response from TI. this behavior has probably something to do with the used IRQ channel on ARM side. ARM uses IRQ 93 and 94 which are related to the EDMA3CC1. This is the CC what I use. Only for testing purpose, I want to deactiv...
08/29/2013
- MW 08:31 PM Software Development: RE: tcDspFirmware::print_version_info() writes past end of buffer
- Hi John,
Thanks for the information, we'll patch this up for the next release. I'm very sorry for the bug (and curious why our SA tool didn't catch this one).
-Mike
- print_version_info() can write more bytes than the 'anMaxLen' argument. The workaround is to pass it a large enough buffer, one that holds the full version string.
Details:
The declaration is
static void print_versio... - CR 07:38 AM Software Development: RE: OMAPL138 DSP-EDMA3 transfer from EMIFA when Linux is running on ARM
- Thanks Mike for your quick answer!
I don't think so that it has something with my used timer(Timer64P3) to do. I put the suspend source of this timer to the DSP and when i stop the DSP with the debugger, the ARM system is well running... - MW 07:14 AM Software Development: RE: OMAPL138 DSP-EDMA3 transfer from EMIFA when Linux is running on ARM
- I suspect that linux may be using the same EDMA resources or interrupts.
I think that the linux ARM-9 port may use a timer and interrupt for generating it's local scheduler clock. You might try a different timer.
-Mike
- Hi,
I'm not sure if this forum is the right place to post this question but i will do it an hopefully anybody can help me.
First I developed my DSP-application without having the Linux an the ARM core running. The DSP app shell cop...
08/28/2013
- 华罗 05:37 AM PCB Development: RE: The schematic of MityDSP-L138 Development Kit
- Hi,tom
please e-mail me the link to download the design files for the MityDSP-L138F schematic,thx!
08/26/2013
- MF 02:08 PM Software Development: RE: EMIFA Clock not present
- The clock started working after some FPGA machinations.
New problem:
We can read registers from the FPGA but can't write:
Here's the code on the ARM side:
08/24/2013
- RK 10:11 AM Software Development: RE: DSP EDMA IRAM DATA TRANSFER
- Solved !
The problem was in the declaration of arrays to which I have copied the content of pointers. If you generally stick to these rules:
-Declare static pointers and initialize their values in the DSP/BIOS task
-Do not modify ...