Critical Link Support: David Ricehttp://support.criticallink.com/redmine/http://support.criticallink.com/redmine/redmine/favicon.ico?16338348402023-11-02T02:35:01ZCritical Link Support
Redmine MitySOM-5CSX Altera Cyclone V - PCB Development: RE: MSEL[4] and return current cap...http://support.criticallink.com/redmine/boards/46/topics/6533?r=6536#message-65362023-11-02T02:35:01ZDavid Ricedavid.rice@criticallink.com
<p>Sorry if I wasn't clear. The caps are optional. They might help in a worst case situation, but for most designs they are overkill. Leaving one off won't be a problem. If you are doing a design and have the option to put them on, it wouldn't hurt to put them on.</p>
<p>The bottom line is that we have never seen a case where these caps matter, but they were included in the design originally, just in case. There's no analytical way to tell if they are needed or not. There are lots of ground connections on the SOM, so the additional ground current paths that these caps might provide are probably unnecessary in any conceivable design. Like most engineers, our designers tend to err on the side of over-design, and it's not worth the cost to try to test if something like these caps are actually needed.</p>
<p>That's not a very clear answer, but there isn't a clear answer. I would be completely comfortable, based on my 42+ years of experience, leaving these caps off. I hope that helps.</p>
<p>Dave</p> MitySOM-5CSX Altera Cyclone V - PCB Development: RE: MSEL[4] and return current cap...http://support.criticallink.com/redmine/boards/46/topics/6533?r=6534#message-65342023-11-01T19:38:09ZDavid Ricedavid.rice@criticallink.com
<p>The intention of the caps to ground on these signals is to allow some high frequency ground currents from the SOM I/O's going off-SOM to have additional paths to ground, since the MSEL signals (and other listed signals) are essentially DC and not switching. If you are running a fully loaded FPGA running at max speed on all I/O's, these additional caps MIGHT provide some help. They are more insurance policy than anything. Certainly leaving off the cap on a few of these signals should have minimal impact.</p>
<p>Dave Rice</p> MityDSP-L138 (ARM9 Based Platforms) - Software Development: RE: uPP receiving problemhttp://support.criticallink.com/redmine/boards/10/topics/4064?r=4072#message-40722014-07-21T11:46:59ZDavid Ricedavid.rice@criticallink.com
<p>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.</p>
<p>I'm not sure why the code is stepping oddly. Perhaps you have optimization on? You might have to talk to TI about that.</p>
<p>Dave</p> MityDSP-L138 (ARM9 Based Platforms) - Software Development: RE: uPP receiving problemhttp://support.criticallink.com/redmine/boards/10/topics/4064?r=4069#message-40692014-07-21T11:09:01ZDavid Ricedavid.rice@criticallink.com
<p>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.</p>
<p>Typically, you will queue up 2 DMA's and as each completes, another DMA will be queued up to ensure that there is always a buffer available, and no data will be dropped.</p>
<p>Dave</p> MityDSP-L138 (ARM9 Based Platforms) - Software Development: RE: uPP receiving problemhttp://support.criticallink.com/redmine/boards/10/topics/4064?r=4067#message-40672014-07-21T10:05:48ZDavid Ricedavid.rice@criticallink.com
<p>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.</p>
<p>The receive command is the start from the software point of view.</p>
<p>I haven't used the FPGA start input, so I can't say, but if you leave it active all of the time, I would tell the UPP to ignore it.</p>
<p>Most problems we have run into on UPP applications have been incorrect initialization or interrupts. Once you get it set up correctly, the code should work.</p>
<p>Dave</p> MityDSP-L138 (ARM9 Based Platforms) - Software Development: RE: uPP receiving problemhttp://support.criticallink.com/redmine/boards/10/topics/4064?r=4065#message-40652014-07-21T09:49:45ZDavid Ricedavid.rice@criticallink.com
<p>A couple of things that I see are different from some code that I have working here:</p>
<p>I use nHWInterruptLevel = 7. Perhaps level 4 is already in use...<br />I use nTskPriorityChanA = 11.<br />I don't use bChanAUseStart = true. I set this to false. It depends on how your FPGA core is set up....</p>
<p>The rest of your initialization looks good.</p>
<p>You'll also want to carefully evaluate your FPGA outputs. If they are not correct, of course, you won't receive anything.</p>
<p>Dave</p> MityDSP-L138 (ARM9 Based Platforms) - Software Development: RE: uPP delay between transmissionshttp://support.criticallink.com/redmine/boards/10/topics/3974?r=4001#message-40012014-07-03T08:29:48ZDavid Ricedavid.rice@criticallink.com
<p>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 go through cache, so it only sees the uninitialized buffer. You must to a cache flush on the txbuffer before calling the transmitDMA function. (I don't believe that the transmitDMA function does the flush under the covers -- you have to do it yourself.)</p>
<p>Please refer to:</p>
<p><a class="external" href="https://support.criticallink.com/redmine/projects/arm9-platforms/wiki/Cache_and_Memory">https://support.criticallink.com/redmine/projects/arm9-platforms/wiki/Cache_and_Memory</a></p>
<p>This explains the issue and mentions the DSP/BIOS calls that you need to use.</p> MityDSP-L138 (ARM9 Based Platforms) - Software Development: RE: DSP DMA crashes Linuxhttp://support.criticallink.com/redmine/boards/10/topics/3183?r=3805#message-38052014-05-09T10:24:18ZDavid Ricedavid.rice@criticallink.com
<p>I have recently been working on a project where we ran into conflicts between QDMA's on the DSP side and MMC use on the ARM side. After much wandering around in the source code, it appears that the ARM code doing DMA for the MMC is using PaRAM resources that the DSP is also using for QDMA's. To resolve this, I now initialize the EDMA drivers on the DSP side to indicate that the DSP doesn't own the DMA channels associated with MMC, and, similarly, that it doesn't own the bottom half of the PaRAM resources. This forces the QDMA's to use high-numbered PaRAMs, which keep it well away from any likely usage by the MMC. After making this change, our system is now working very reliably.</p>
<p>Here's the change I made in the QDMA source code:</p>
<pre><code>initCfg.drvInstInitConfig->ownPaRAMSets[0] = 0x0FFFFFFFu;<br /> initCfg.drvInstInitConfig->ownPaRAMSets[1] = 0x00000000u;<br /> initCfg.drvInstInitConfig->ownDmaChannels[0] = 0x0FFFFFFFu;</code></pre>
<p>I added these lines just prior to the EDMA3_DRV_open() call.</p>
<p>Dave</p> MityDSP-L138 (ARM9 Based Platforms) - Software Development: RE: DSP- EDMA Transmission problemhttp://support.criticallink.com/redmine/boards/10/topics/3493?r=3670#message-36702014-02-24T07:38:08ZDavid Ricedavid.rice@criticallink.com
<p>Excellent! Glad it is now working!</p>
<p>Dave</p> MitySOM-5CSX Altera Cyclone V - FPGA Development: RE: Ethernethttp://support.criticallink.com/redmine/boards/47/topics/3379?r=3593#message-35932014-01-30T09:31:30ZDavid Ricedavid.rice@criticallink.com
<p>Greg,</p>
<p>Only 2 "e"s in setenv, not three... Jack probably knows that, but just to be clear...</p>
<p>Dave</p> MityDSP-L138 (ARM9 Based Platforms) - Software Development: RE: DSP- EDMA Transmission problemhttp://support.criticallink.com/redmine/boards/10/topics/3493?r=3494#message-34942013-12-20T11:46:19ZDavid Ricedavid.rice@criticallink.com
<p>I'm not sure why you are dividing by 4 for the number of words to transfer (numwords>>2), but I think that is your problem. ii will be set to 1024 in the example you show, so it should transfer 1024 16-bit words, which is what you are seeing. If you want to transfer 4096 words, you need to set ii to 4096, or set up 4 transfers. Also, is your FPGA set up to map 4k words of data space for your data interface? If you intend to transfer 4k at once, you'll need to make sure the FPGA is set up to deliver those words. That won't affect the number of words to transfer, so that's not related to the problem at hand, but it could be the next problem you run into!</p>
<p>Dave</p> MityDSP-L138 (ARM9 Based Platforms) - Software Development: RE: Can't get DMA using low level dri...http://support.criticallink.com/redmine/boards/10/topics/3227?r=3289#message-32892013-10-25T08:46:43ZDavid Ricedavid.rice@criticallink.com
<p>If you have cache enabled for the DDR, I don't think it should be much faster to use IRAM. Your DMA in this case will complete when the data is in cache, not when it is in DDR.</p>
<p>Transfers from the EMIF interface are not very efficient. As Mike says, the crossbar in the OMAP makes EMIF transfers very slow.</p>
<p>Dave</p> MityDSP-L138 (ARM9 Based Platforms) - Software Development: RE: Can't get DMA using low level dri...http://support.criticallink.com/redmine/boards/10/topics/3227?r=3234#message-32342013-10-08T16:12:25ZDavid Ricedavid.rice@criticallink.com
<p>You bring up a very good point. If you are only moving 16 words every 4us, the overhead to setup the DMA may be too much to make it worth doing that.</p>
<p>Do you have a latency requirement (i.e., how may microseconds from the time the data is digitized to the time you have to finish processing it?). Can I assume that you are using the FPGA version of our module? If so, the way we would typically architect a system like this is to have the FPGA collect the data from multiple conversions and store them in a FIFO. The FIFO would then interrupt the DSP when it gets half full, and the DSP would DMA a number of words corresponding to half of the FIFO. Typically we would use a FIFO of 512 or 1024 words, so you'd get interrupted every 256 or 512 words. In your case, that'd be about 64 or 128 microseconds (16 or 32 four-microsecond sample times). That will allow you to amortize your overhead over more samples.</p>
<p>If you must process every 4us, it may still be necessary to use DMA -- the L138 is extremely slow when having the DSP read from the EMIF. It seems the DSP has to go through some sort of request/grant cycle internally to get the bus to do each transfer.</p>
<p>Let me know if that is helpful.</p>
<p>Dave</p> MityDSP-L138 (ARM9 Based Platforms) - Software Development: RE: Can't get DMA using low level dri...http://support.criticallink.com/redmine/boards/10/topics/3227?r=3231#message-32312013-10-08T15:19:46ZDavid Ricedavid.rice@criticallink.com
<p>The QDMA can be used for just about anything the EDMA can be used for, in terms of transfers, but it can't be triggered by an external event -- it is software triggered. What this means is that you have to have an interrupt handler to respond to an interrupt, and then issue a QDMA to do the transfer. Typically the QDMA posts a semaphore when complete so you can have a task pend on the SEM in order to do whatever comes next. QDMA handles moving data to/from the EMIF (FPGA) quite nicely. It can transfer from a FIFO (non-incrementing read pointer) in an FPGA to internal or external memory. We use this capability routinely.</p>
<p>If your issue is that you aren't seeing the data moving (but you get a DMA complete interrupt), it is quite possible that it is a cache issue, as Mike pointed out. Normally, you want cache enabled for all DDR memory accesses, since it provides a huge performance boost for the DSP. However, any memory changes performed by a peripheral, such as the DMA engines, do not to through the cache. So, for example, if you want to write a block of memory from the DSP, and then DMA that memory to another location, then read it with the DSP, you must do the following:</p>
<p>Write data from DSP to memory.<br />Flush the cache for that memory area.<br />Initiate the DMA<br />Invalidate the cache for the destination area<br />Read the results.</p>
<p>Although this example is a bit stupid -- it illustrates the steps required.</p>
<p>The FPGA memory space is not cached, normally, so you don't need to worry about cache when reading/writing to the FPGA.</p>
<p>When looking at memory in the debugger memory window, there are checkboxes to allow you to look at cached and non-cached views of the memory.</p>
<p>By the way, one VERY important thing to keep in mind. Always use memory blocks that start and end on 128 byte boundaries when dealing with the cache! The cache uses "cache lines" which are 128 bytes long, so if you don't align your buffers, you can end up trashing adjacent data when you flush or invalidate your cache.</p>
<p>We typically use the DSP/BIOS CACHE_xxxx calls to flush (writeback) and invalidate the cache.</p>
<p>Dave</p> MityDSP-L138 (ARM9 Based Platforms) - Software Development: RE: Can't get DMA using low level dri...http://support.criticallink.com/redmine/boards/10/topics/3227?r=3228#message-32282013-10-08T13:01:07ZDavid Ricedavid.rice@criticallink.com
<p>Hi Steven,</p>
<p>I looked briefly at your code and nothing jumped out at me...</p>
<p>I am the one who developed Critical Link's QDMA class for use on this module, although it was a couple of years ago. I do remember that it was a very painful process!! One thing to consider -- the ARM does not use the QDMA resources, so if using the QDMA is a possibility, I strongly suggest doing so. In fact, if you haven't looked at using our QDMA class, which encapsulates all of the madness surrounding getting the QDMA working, you may want to have a look. If it will provide you with what you need, it's probably a much faster path to a solution. I've used it on several projects recently, and it is pretty bullet-proof. I don't know if there is a good example of using it, but I can probably give you some code snippets to help you along.</p>
<p>Dave</p> MityDSP-L138 (ARM9 Based Platforms) - Software Development: RE: DSP DMA crashes Linuxhttp://support.criticallink.com/redmine/boards/10/topics/3183?r=3203#message-32032013-09-19T16:17:50ZDavid Ricedavid.rice@criticallink.com
<p>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 look around and see what I can find out.</p>
<p>Dave</p> MityDSP-L138 (ARM9 Based Platforms) - Software Development: RE: DSP DMA crashes Linuxhttp://support.criticallink.com/redmine/boards/10/topics/3183?r=3196#message-31962013-09-18T17:46:50ZDavid Ricedavid.rice@criticallink.com
<p>Hi Lars,</p>
<p>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.</p>
<p>You could also try another hardware interrupt. I'm using interrupt 8 in my application and that's working fine. Maybe try that instead of 7?</p>
<p>Dave</p> MityDSP-L138 (ARM9 Based Platforms) - Software Development: RE: DSP DMA crashes Linuxhttp://support.criticallink.com/redmine/boards/10/topics/3183?r=3194#message-31942013-09-18T13:08:37ZDavid Ricedavid.rice@criticallink.com
<p>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 Options | Linker in CCS3.3 -- not sure exactly where in CCS 4 or 5):</p>
<p>$(L138_2013-05-15)/sw/3rdparty/edma3lld_01_11_00_03/packages/ti/sdo/edma3</p>
<p>and make sure you have the following in your Incl. Libraries (under project Build Options | Linker):</p>
<p>drv/lib/Release/edma3_drv_bios.lib;drv/sample/lib/c6748/Release/edma3_drv_bios_sample.lib;rm/lib/c6748/Release/edma3_rm_bios.lib</p>
<p>These should pull in the necessary code for the L138.</p>
<p>Dave</p> MityDSP-L138 (ARM9 Based Platforms) - Software Development: RE: DSP DMA crashes Linuxhttp://support.criticallink.com/redmine/boards/10/topics/3183?r=3192#message-31922013-09-18T11:26:30ZDavid Ricedavid.rice@criticallink.com
<p>Hi Lars,</p>
<p>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.</p>
<p>Dave</p> MityDSP-L138 (ARM9 Based Platforms) - Software Development: RE: Calculating FFT using SigProcTIDs...http://support.criticallink.com/redmine/boards/10/topics/3048?r=3049#message-30492013-08-04T14:52:41ZDavid Ricedavid.rice@criticallink.com
<p>I think your problem is here:</p>
<p>for(int i=0;i!=FFT_SIZE;i+=2)
{<br /> mpWorkBuff[i]=sin21[i];<br /> mpWorkBuff[i+1]=sin42[i];<br />}</p>
<p>Your indices for the two sin waves are incrementing by two, while they should be incremented by one.</p>
<p>Try this:</p>
<p>for(int i=0;i<FFT_SIZE;i++)
{<br /> mpWorkBuff[2*i]=sin21[i];<br /> mpWorkBuff[2*i+1]=sin42[i];<br />}</p>
<p>That may not be the only problem, but it certainly is part of the problem. Let me know if that helps.</p>
<p>Dave</p> MityDSP-L138 (ARM9 Based Platforms) - Software Development: RE: ethernet over USB don't workhttp://support.criticallink.com/redmine/boards/10/topics/2673?r=2674#message-26742013-05-04T09:24:53ZDavid Ricedavid.rice@criticallink.com
<p>I think you are using the wrong approach to do this. The RNDIS driver (g_ether.ko) is to allow IP over USB and is a USB peripheral (not host) driver. It sets the USB port on the ARM to look like a remote Ethernet adapter to a PC that is connected via USB cable. This allows you to plug in the ARM USB OTG or peripheral port to a PC and have the PC "see" a new Ethernet adapter. There is no actual Ethernet controller chip involved -- it is USB to USB only.</p>
<p>You have selected the driver for the smsc7500 in menuconfig, so that should enable the support you need. Did you enable it to be compiled into the kernel [*] or as a module [M]? If you selected [*] in menuconfig, you don't need to load a .ko file. If you selected [M], you'll need to find the correct kernel module to load. In this case, the correct module is probably smsc75xx.ko. If you selected [M] you will also need to do a "make modules" to compile associated kernel modules in order to build the .ko file.</p>
<p>Dave</p> MityDSP-L138 (ARM9 Based Platforms) - Software Development: RE: Using dspQDMA library on OMAP-L138http://support.criticallink.com/redmine/boards/10/topics/875?r=889#message-8892011-10-20T12:41:53ZDavid Ricedavid.rice@criticallink.com
<p>Mike and I apparently were typing simultaneously! Good thing we both came up with the same answer!<br />Dave</p> MityDSP-L138 (ARM9 Based Platforms) - Software Development: RE: Using dspQDMA library on OMAP-L138http://support.criticallink.com/redmine/boards/10/topics/875?r=888#message-8882011-10-20T12:40:44ZDavid Ricedavid.rice@criticallink.com
<p>Typically, we kick off the DMA from an ISR and pend for it in a task. Pending from within an ISR is not allowed. You could kick off the DMA from with the timer function, and pend for the semaphore within a monitoring task. This will avoid the problem of pending in the ISR, and allows the task switch to occur at the same time as the DMA transfer is happening, so the overhead to do the task switch would be (at least partially) covered by the transfer time. Set the priority of the DMA monitoring task pretty high so it doesn't get blocked by a lower priority task.</p>
<p>Dave</p>