Activity
From 06/22/2014 to 07/21/2014
07/21/2014
- JC 12:41 PM Software Development: RE: uPP receiving problem
- The strange stepping sounds exactly like when optimizations are turned on.
- DR 11:46 AM Software Development: RE: uPP receiving problem
- I'm not a VHDL guy, so I can't say whether this will work as you have it. It sounds like you and your VHDL guy should sit together and verify that it is correct. It's best to do this using ChipScope.
I'm not sure why the code is ste... - SB 11:34 AM Software Development: RE: uPP receiving problem
- Here you can find the VHDL sources.
I cannot help you a lot with VHDL becuse it is developed by a colleague of mine.
Thanks in advance another time to help me.
Silvano - SB 11:19 AM Software Development: RE: uPP receiving problem
- Thanks a lot.
Now the working principles are clearer.
The problem now is that the software has a strange behaviour.
During the debug operations and the step by step execution, sometimes, after the receive() call, it steps itself back ... - DR 11:09 AM Software Development: RE: uPP receiving problem
- Each time you call receive, a DMA is set up to fill the buffer you pass. Once that DMA completes, no data will be transferred into memory until another DMA is queued up.
Typically, you will queue up 2 DMA's and as each completes, ano... - SB 10:08 AM Software Development: RE: uPP receiving problem
- Ok thank you.
I will try to change all the interrupt levels.
Another question is: but once the buffer is filled? What happens? It stops to receive?
Thanks. - DR 10:05 AM Software Development: RE: uPP receiving problem
- I don't see any reason that it wouldn't work, but I have seen issues with some interrupt levels not working. I strongly recommend that you try some different ones.
The receive command is the start from the software point of view.
... - SB 09:59 AM Software Development: RE: uPP receiving problem
- Thanks to have a look.
I have the signal enable and start always active.
I think that therefore is right to set bChanAUseStart to true.
I can check all the interrupt level... but i do not think that is a problem.
But supposing the co... - DR 09:49 AM Software Development: RE: uPP receiving problem
- A couple of things that I see are different from some code that I have working here:
I use nHWInterruptLevel = 7. Perhaps level 4 is already in use...
I use nTskPriorityChanA = 11.
I don't use bChanAUseStart = true. I set this to ... - Dear all,
I am trying to use to uPP to receive data coming from the FPGA.
Attached you can find the code I wrote. Aim of the code should be:
- receive only on the channel A.
- the receiver buffer is 4096 lines and each lines is m...
07/15/2014
- NP 04:39 AM Software Development: RE: How to enable PRU Subsystem on MityDSP-L138F SOM ???
- Hi Jonathan,
Thank you for your patches, it's working for me!
I have applied and successfully rebuilt my kernel.
And almost PRU example from TI can run on my board.
Thanks you very much! ^^
_Regard,
Manh BT
07/14/2014
- JC 11:39 AM Software Development: RE: How to enable PRU Subsystem on MityDSP-L138F SOM ???
- Ngoc,
Can you confirm that this is working for you and i'll move the changes into our main kernel branch?
I also created a wiki page to help future projects [[Using PRU]] - JC 10:51 AM Software Development: RE: How to enable PRU Subsystem on MityDSP-L138F SOM ???
- gpioToggle test passed when i just ran it. Not sure why.
- JC 10:24 AM Software Development: RE: How to enable PRU Subsystem on MityDSP-L138F SOM ???
- Reran some of the commands to see which fail. The ./PRU_memAccessL3andDDR can cause system segfaults as it appears to use a fixed part of ddr during its test and if a program or linux happens to be residing there then it will be overrid...
- JC 09:11 AM Software Development: RE: How to enable PRU Subsystem on MityDSP-L138F SOM ???
- Running through all the examples, atleast one of them seems to have caused a system segfault as not even reboot was able to run afterwards.
- JC 09:09 AM Software Development: RE: How to enable PRU Subsystem on MityDSP-L138F SOM ???
- Hi Ngoc,
I have been working on getting this to work. So far i've integrated the patches which i've posted to a test branch until we can confirm its working. Please checkout 'mitydsp-linux-v3.2_pruss_wip' branch. Currently it is cr... - NP 04:45 AM Software Development: RE: How to enable PRU Subsystem on MityDSP-L138F SOM ???
- Hi,
Thank you, I'm waiting for your patches. ^^
Regards,
Manh BT - JC 09:25 AM Software Development: RE: uBoot and USB using L138F SoM
- I have been looking into this. It seems that it was a mistake as the added resistor isn't mentioned in our Engineering change request. I noticed the added resistor recently when I was working towards getting the OTG feature working. C...
- SE 03:28 AM Software Development: RE: uBoot and USB using L138F SoM
- OK, the cable that I used was a miniAB to USB A plug which was then attached to a USB A to USB A gender changer (a little crude, but it works).
Dare I ask why did you add a pull down resistor on your revision C board if the specificat...
07/13/2014
- BD 10:18 PM Software Development: RE: How to enable PRU Subsystem on MityDSP-L138F SOM ???
- Hello Manh BT,
The patches Mike described are in the mainline Linux kernel (http://kernel.org/). You can search for those commit hashes via Google to see the required changes.
We are in the process of applying and testing these pat... - NP 09:42 PM Software Development: RE: How to enable PRU Subsystem on MityDSP-L138F SOM ???
- Hi Michael,
Thanks for your information, but where can I get above patches? Is it in Critical Link MDK ?
Regard,
Manh BT
07/11/2014
- JC 01:30 PM Software Development: RE: uBoot and USB using L138F SoM
- As per the On-The-Go spec, the mini USB adapter is supposed to tie the USB_ID pin to GND to indicate it should be put into host mode.
http://en.wikipedia.org/wiki/USB_On-The-Go#OTG_mini_plugs
http://www.amazon.com/Host-Cable-fema... - SE 12:36 PM Software Development: RE: uBoot and USB using L138F SoM
- Yep, loading an image seems to be OK. Next week I'll try the whole image + rootfs and make sure that works too.
Thanks! (sometimes you just need a nudge in the right direction!) - SE 12:20 PM Software Development: RE: uBoot and USB using L138F SoM
- OK, now I get it. There's no resistor on my board pulling the ID pin down to 0V. I've just put a link between pins 4 & 5 on J100 and its all OK now.
I'll try putting an image on there for it to boot from and let you know. - SE 12:07 PM Software Development: RE: uBoot and USB using L138F SoM
- The number is 80-000286RI-2
REV B
S/N 132556
Which bootloader are you using? I've been using my own compilation but that is wholly based on the one taken from the Git repository from your wiki link with no modifications. - JC 12:05 PM Software Development: RE: uBoot and USB using L138F SoM
- Whats the part number of your dev kit? Should be a 80- number.
- JC 12:03 PM Software Development: RE: uBoot and USB using L138F SoM
- I just tested this by first plugging the flash drive into the full size usb port J102. With no luck. Then plugged drive into J100 via adapter cable and it was discovered. See log below.
- SE 11:43 AM Software Development: RE: uBoot and USB using L138F SoM
- I forgot to say that I know that the USB port works because, once in Linux I can mount the drive OK and read/write files etc.
USB drive is plugged into J100 via an adapter cable. - Hi there,
I'm using the L138F SoM on a REV B Industrial I/O board and I am trying to boot from a USB drive. uBoot is configured for USB but when I try:
@usb start@
All I get is:
@(Re)start USB...
USB: scanning bus for devic... - MW 08:31 AM Software Development: RE: How to enable PRU Subsystem on MityDSP-L138F SOM ???
- Hi,
I think we need to add the following patches (from linus tree) to the kernel to instantiate the PRUSS drivers for the L138.
2eb2478d471e45e1d0c8bb3defbf82bf7204e13d uio: uio_pruss: replace private SRAM API with genalloc
8e0d72... - Hi everyone!
I'm using MityDSP-L138F SOM + IO Industrial Board and now trying to work with PRU subsystem of OMAP-L138 processor.
I've found some instructions from:
http://processors.wiki.ti.com/index.php/PRU_Linux...
07/03/2014
- UF 02:45 PM Software Development: RE: uPP delay between transmissions
- It was a cache invalidation issue. Calling BCACHE_wb() solved the problem.
I did find a small bug in the trasmit() code: - DR 08:29 AM Software Development: RE: uPP delay between transmissions
- My first thought on seeing this is that it is probably a cache issue. After you set the values in the buffer, the values are in the cached version of the buffer, but haven't be written to external RAM. When you do the DMA, it doesn't g...
07/02/2014
- UF 06:47 PM Software Development: RE: uPP delay between transmissions
- We cannot get the uPP to work. For test we just use the FPGA to pass the uPP pins to FPGA output pin. The Enable pin works fine, but the Data pins make no sense. Attached is an image showing the Enable pin in pink and a data pin in blue....
- MW 07:19 AM Software Development: RE: uPP delay between transmissions
- Ah, yes, I am sorry I forgot about the EMIFA scheduling delays. You are correct.
If you are using the reference Platform.tci DSP/BIOS configuration from the BSP, try the "IRAM" section.
I believe the L2 (256K total) is setup as 1... - UF 12:55 AM Software Development: RE: uPP delay between transmissions
- We started with EMIFA. We got a delay of 11uSec between transfers as discussed in this post:
https://support.criticallink.com/redmine/boards/12/topics/3903?r=3942#message-3942
This seems way slower than your expectations. Removing ... - SB 11:49 AM Software Development: RE: Linker error on DSP application with Code Composer 6
- Thanks a lot to everybody.
It was a simple linker problem.
Silvano - Hello everybody.
We see an unexpected behaviour during simple debugging operations.
/*
* main.c
*/
#include <stdio.h>
#include <std.h>
#include <log.h>
#include "testcfg.h"
int pippi[1000];
Void main(void)
{
shor...
07/01/2014
- JC 04:30 PM Software Development: RE: Linker error on DSP application with Code Composer 6
- Note i found the generic c674x device under target: generic devices
!DSP_C674x.png! - GD 03:39 PM Software Development: RE: Linker error on DSP application with Code Composer 6
- Silvano,
Have you followed our guide to building a Hello World application?
https://support.criticallink.com/redmine/projects/arm9-platforms/wiki/DSP_Hello_World
The steps for setting up a proper build environment and building D... - Dear all,
we are trying to build a simple application on DSP using Code Composer 6 plus DSP/BIOS.
In the following the very simple code:
/*
* main.c
*/
#include <std.h>
#include <log.h>
#include <stdio.h>
#include "Testcf...
06/30/2014
- MW 04:18 PM Software Development: RE: uPP delay between transmissions
- Have you tried just writing to the FPGA via EMIFA? That would be a 16 2-byte word transfer. Even with 10 wait states (using 100 MHz EMIFA bus), that would be < 2 usecs. I think by default we use 5 wait states with address demuxing opt...
- UF 03:11 PM Software Development: RE: uPP delay between transmissions
- Re-architecting our code is not really a vaiable solution. We have a feedback loop running in the DSP, that depends on data that should be read from the FPGA and be used to generate the next packet. The DSP loop is too complicated to be ...
06/28/2014
- GG 04:22 AM Software Development: RE: uPP delay between transmissions
- Hello,
First of all, using such small packet size you may not be able to completely eliminate the delay between sending packets. There is an overhead associated with programming the uPP DMA engines. So, you may want to consider the p...
06/27/2014
- We are trying to use uPP to send data from the DSP to the FPGA. The problem is that there is a delay of about 8 micro seconds between packets being send.
This is the code we use in the DSP:
06/26/2014
- BD 11:22 AM Software Development: RE: SSD on MityDSP-L138F
- Hannes,
As mentioned in the errata, they do not recommend the "reset" approach because they cannot guarantee that it will work in a reasonable amount of time.
If you are going to go down this path, I suggest you test this approach ... - JC 08:25 AM Software Development: RE: Where to download the document about Memory Map and Register Address of IO Board 80-000268RI-2C and OMAPL138F
- These are provided by TI. You can find them here: http://www.ti.com/product/OMAP-L138/technicaldocuments
You should start with the "OMAP-L138 C6000 DSP+ARM Processor (Rev. H)" Datasheet and the "OMAP-L138 C6000 DSP+ARM Processor Techn... - MW 08:16 AM Software Development: RE: Where to download the document about Memory Map and Register Address of IO Board 80-000268RI-2C and OMAPL138F
- The memory map of the OMAP-L138 can be found on TI's main "OMAP-L138 web page":http://www.ti.com/product/omap-l138 (see the datasheet and the technical reference manual).
Not sure if that is what you are looking for.
06/25/2014
- only some brief documents are found in wiki,
Where can I download the document about Memory Map and Register Address of the IO Board 80-000268RI-2C and OMAPL138F? - LY 04:02 PM FPGA Development: RE: DSP to FPGA SPI Setup Question
- Hello,Mike
Thank you very much.
- MW 12:42 PM FPGA Development: RE: DSP to FPGA SPI Setup Question
- What is your target update rate? Continuous?
You might try first to rip out all of the overhead on the tcDspFpgaSpi.cpp code (there is LCK_pend()/LCK_post() for serialization control, etc) and boil it down to the register writes.
... - LY 11:32 AM FPGA Development: RE: DSP to FPGA SPI Setup Question
- Hello,Mike
Thank you for your help.
I have attached two pic
----one is the SPI bits transfer rate(This is our desired speed),
----another one is the word to word transfer rate(This is slow. We want it can be fast,Could you give u... - MW 10:47 AM FPGA Development: RE: DSP to FPGA SPI Setup Question
- Can you check with a scope at what the clock rate is on the SPI device, and the interword write delay? I just want to confirm they are getting 50 MHz clock rate.
It might be the EMIFA transfer, but we should confirm that the SPI de... - AB 10:39 AM FPGA Development: RE: DSP to FPGA SPI Setup Question
- Update and followup question from the customer:
We have made the SPI work, but transmitting the word to word is slow.(about 11 uSec to send a 24bit word).
This is the code we run in the DSP:
spi = new tcDspFpgaSpi((void *)my_bas... - MF 12:01 PM Software Development: RE: Interrupting the ARM from the DSP
- Thanks. This does what I wanted.
On the DSP side: - MW 09:11 AM Software Development: RE: Interrupting the ARM from the DSP
- I think that you are confusing signals and interrupts a bit.
You need to write some kernel module code to register an ISR handler for the CHIPSIG (which may already being used by DSPLINK) and forward/create the signal condition you ar... - MF 08:26 AM Software Development: RE: Interrupting the ARM from the DSP
- Yes, I am familiar with DSPLink and am using it. However, I have time requirement that DSPLink cannot meet. Polling uses too much CPU time. Interrupt would be the most efficient. I just need to know how to connect the CHIPSIG interrup...
- HK 08:01 AM Software Development: RE: USB2.0 Host on MityDSP-L138F
- There you are. Note that i had to change the initialization in the code as noted above.
- MW 07:26 AM Software Development: RE: USB2.0 Host on MityDSP-L138F
- If you don't mind, could you post your config.gz file?
- HK 05:37 AM Software Development: RE: USB2.0 Host on MityDSP-L138F
- Hey again,
i tried changing it from DMA to PIO. Now, everything seems to work. Device is readable, writable and mountable. Performonce is ok - about 8MB/s either way.
The ethernet problem is gone. I'm not sure where the problem was... - Hey folks,
I'm trying to use a SSD instead of a HDD on the L138F.
I found in the errata that the OMAP-L138 has a problem with SATA devices capable of SATA 3. I'm using a Samsung 840 evo.
The kernel detected the disk once, but ... - AM 02:12 AM Software Development: RE: TPS65023 VDCDC2 and VDCDC3 constraints
- Jonathan, thank you, I will track your branch.
06/24/2014
- GG 05:41 PM Software Development: RE: Interrupting the ARM from the DSP
- Hello Mary,
I'm not sure what the problem is in your specific example as we almost always use DSPLink to to communicate between the ARM and DSP. We have wrapper classes that allow for passing messages between the DSP and ARM, and uti... - I would like to have the DSP (running BIOS 5) interrupt the ARM (running Linux MDK_2012-08-10)
In the DSP Code: - JC 12:04 PM Software Development: RE: TPS65023 VDCDC2 and VDCDC3 constraints
- Andrey,
Not sure if its any help but I've pushed a work in progress 3.14 branch to our git. Its based off the mainline 3.14.y branch. Haven't been able to get SPI working so the ethernet isn't getting initialized as its configured fr...
06/23/2014
- ES 10:25 AM PCB Development: RE: MityDSP-L138 processor running hot
- All unused connections are no connects.
- ES 09:59 AM PCB Development: RE: MityDSP-L138 processor running hot
- I have attached a plot showing the rise of the supply on the baseboard (channel 2) and the Mity card (channel 1). As you can see there is a droop in the supply on the card. I assume there is a switch mode regulator to generate the 1.8V f...
- MW 09:54 AM PCB Development: RE: MityDSP-L138 processor running hot
- What are you doing with unused connections on the module?
- ES 09:52 AM PCB Development: RE: MityDSP-L138 processor running hot
- It remains hot until the next power cycle. A reset cycle alone does not give an improvement.
- MW 09:15 AM PCB Development: RE: MityDSP-L138 processor running hot
- On non-FPGA variants, DVDD3318_A, DVDD3318_B, and DVDD3318_C are all tied to 3.3V.
Does the issue only occur during reset, or once the unit boots it remains "hot" until another power cycle or reset cycle? - ES 09:07 AM PCB Development: RE: MityDSP-L138 processor running hot
- All our I/O to the card is 3.3V. The OMAP processor has 3 configurable power groups which can be connected to 3.3V or 1.8V. I believe you have them all connected to 3.3V but as I don't have your circuit I cannot verify this. Could you co...
- MW 07:56 AM PCB Development: RE: MityDSP-L138 processor running hot
- Ok.
I suspect the issue may be related to I/O voltage levels (you have I/Os being driven or pulled to a value larger than the bank voltage), or during reset the OMAP-L138 typically pulls most of it's I/O pins (internally) to +VDD of w... - ES 07:51 AM PCB Development: RE: MityDSP-L138 processor running hot
- We are using a baseboard developed for our application. I'm happy to share the schematic. Let me know how to get that to you. The variant we are running is without the FPGA.
I have managed to measure the excess current draw. When it i... - MW 07:06 AM PCB Development: RE: MityDSP-L138 processor running hot
- Hi Ed,
Are you running on a DevKit or on a custom board? Would you be willing to share your schematic (privately to CL, not via this forum page)? Are you using an FDGA variant or processor only variant of the module?
-Mike
- We are some way into the development of using the MityDSP-L138 platform. I recently noticed that about 50% of the time when the module is powered up the OMAP processor runs very hot, >50C. The other 50% of the time it runs relatively coo...