Activity
From 06/26/2014 to 07/25/2014
07/23/2014
- PS 11:06 PM FPGA Development: RE: fpgautil read Issue
- Hi Mike,
I found the issue. I was updating the edo_out signals only when rd was going high.
From the waveform i found rd signal going high after edo_out is driven on the interface.
It really make sense when updated register v... - MW 08:42 PM FPGA Development: RE: fpgautil read Issue
- Can you post (or email me) you VHDL source related to the loopback register?
Do you have Chipscope? It might be worth using chipscope to track the address / register data through the transfer cycle.
-Mike - I'm using MityDSP-L138 Board. I have implemented a Custom IP in the FPGA board.
I'm using the CS5 ARM Chipselect and using the frame work available in fpga/vhdl directory.
Also, i'm using the fpgautil program in examples dir to read...
07/22/2014
- GG 11:42 AM Software Development: RE: uPP receiving problem
- Hello Silvano,
No, the MDK uPP libraries are not setup to work with the debugger. In your code you can try setting the necessary debug bits, as you pointed out in your last post, after calling the initialize() routine. I remember hav... - SB 08:54 AM Software Development: RE: uPP receiving problem
- The strange behaviour still continue.
When we do not send data to uPP using the FPGA the program does not have the strange stepping.
Whne we send data to uPP the stepping behaviour still remains even if the optimizations are turned off... - SB 03:10 AM Software Development: RE: uPP receiving problem
- Thanks a lot for the suggestion.
I will check with my colleague the VHDL connection.
I also had a check at the optimitations but they are all turned off. It is very strange because it is a very simple program.
Any other suggestion, m...
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.