Activity
From 08/30/2014 to 09/28/2014
09/26/2014
- MA 02:27 AM Software Development: RE: GP0[4] state on boot for L138F
- ??How quickly do you need it to be low? You might put an external pull down on your board.??
Pretty much instantly would be ideal as we use it as a /SHUTDOWN control for some hardware that should only be brought up once the Mity is fu...
09/25/2014
- MW 07:46 PM Software Development: RE: GP0[4] state on boot for L138F
- How quickly do you need it to be low? You might put an external pull down on your board.
You could disable the pull up, but keep in mind the OMAP-L138 controls for the pull up are in groups, so you will affect other pins when you dis... - MA 05:11 PM Software Development: RE: GP0[4] state on boot for L138F
- Hi Mike, thanks for the explanation. As we need this pin to be low on power-up, would the best place to set this be in the U-Boot mityomap config/init code?
- MW 03:40 PM Software Development: RE: GP0[4] state on boot for L138F
- Hi,
If you check the OMAP-L138 datasheet (it's a bit convolved) Table 2-29, the GP0[4] pin pullup state is defined by CP[2] group control in the PUPDENA / PUPDSEL registers after reset completes (during reset it should be pulled down)... - Hi, we noticed that the power on state of GPIO_0_4 is that it is driven high. I am a little confused about this since I can't see anything in the U-Boot source code (u-boot-mitydspl138/board/davinci/mityomapl138/) changing PINMUX1 from t...
09/23/2014
- SB 02:05 PM Software Development: RE: UPP problem
- Problem was caused by cache incoherency. Use of BCACHE_inv() fixed it.
09/22/2014
- JC 10:19 AM Software Development: RE: USB Bug
- There are several missing features in the 3.14 branch that I found when trying to move to it. I created a tag to mark my findings.
http://support.criticallink.com/gitweb/?p=linux-davinci.git;a=tag;h=refs/tags/3.14_Note
I'm not sure o... - JC 10:13 AM Software Development: RE: USB Bug
- Note that we have seen a similar issue on the 335x. Could you checkout the following page and report back if the solution helps?
https://support.criticallink.com/redmine/projects/armc8-platforms/wiki/Using_USB_port - BK 10:11 AM Software Development: RE: USB Bug
- It is from your git page - as far as I remember. Our software student tried to jump to 3.14 two month ago but it didn't work completly so we jumped only to 3.7. as this seemed to work.
- MW 09:39 AM Software Development: RE: USB Bug
- Hello,
Are you using a 3.7 branch from our git site, or the mainline? I don't think we officially support 3.7. Do you see the same behaviour in 3.2?
-Mike - BK 09:37 AM Software Development: RE: USB Bug
- Another thing: When I plug in the first usb device the number of usb interrupts in /proc/interrupts increases. When I unplug it, it stops as expected. But not a single interrupt happens when I plug in another device after unplugging the ...
- Hej hej,
we have noticed a usb bug on the MityDSP and we are not sure why this happens.
We are using linux 3.7.0+-kernel with our own baseboard. The socket is configured and initialized as USB_HOST (with mityomapl138_usb_init(MUSB_...
09/21/2014
- hi,
I am having problems reading data from the FPGA to memory. I set up the UPP interface
using channel A from transmit, channel B for receive, and start the receive transactions
using the code below
#include "evmomapl137.h"
...
09/18/2014
- CB 10:07 AM FPGA Development: RE: Mity L138F FPGA -> OMAP interrupt lines
- Thanks Mike,
I have found the pin mapping for INT0 and INT1 I couldn't find the mapping for the Non Maskable Interrupt (NMI) pin in the table. I also couldn't find the IOSTANDARD to use the interrupt pins.
Chris B.
- MW 09:48 AM FPGA Development: RE: Mity L138F FPGA -> OMAP interrupt lines
- Hi Chris,
The information you need is in Table 4 of the "Carrier Board Design Guide":http://www.criticallink.com/wp-content/uploads/2014/01/MityDSP-L138F-Carrier-Board-Design-Guide.pdf.
-Mike
- I was trying to use an FPGA interrrupt which should be serviced by the DSP core in the OMAP.
From the MityL138.ucf I have the following FPGA pins:
09/16/2014
- MF 09:55 AM Software Development: RE: Adding SPI flash
- The part works in SPI mode 0 or 3, but I tried all four modes (0 - 3). I also tried setting the fields .c2tdelay and .t2cdelay to 0.
As I mentioned, the data appearing on the bus (SOMI), driven by the M25PE80 is correct (as seen with... - MW 09:45 AM Software Development: RE: Adding SPI flash
- Is the SPI mode field correct (polarity and phase, CPOL and CPHA is the part in SPI_MODE_0)?
You also look like you are setting the delay fields (c2tdelay and t2cdelay), required?
- MF 09:06 AM Software Development: RE: Adding SPI flash
- I confirmed with a scope that the chip select was not active.
I added DA850_GPIO2_15 to the the array of gpios in my baseboard file.
I also changed the .type entry in the flash_platform_data structure to "m25pe80".
In this case,...
09/12/2014
- MW 09:19 AM Software Development: RE: Adding SPI flash
- It would not apply (different driver, different logic handling platform arguments).
- JC 09:17 AM Software Development: RE: Adding SPI flash
- Note that if you want to use the hardware designated chip select for that spibus instead of a gpio then the SPI_INTERN_CS variable is used. Unsure if this applies to a fpga spibus though.
09/11/2014
- MW 06:18 PM Software Development: RE: Adding SPI flash
- Hi Mary,
Have you configured the pin-mux for the DA850_GPIO2_15, which would correspond to the chip select you are selecting for your part?
The way you have configured it is you are having the SPI controller drive that chip select ... - We have a SPI serial flash device on our board, an M25PE80. It is connected to SPI1 with SPI1_CS1.
I created a baseboard file based on baseboard-industrialio.c and using what was done for the SPI flash in board-mityopmanl138 as a gui...
09/10/2014
- DB 01:46 PM Software Development: RE: DSP HelloWorld Message Queue Buffer Length
- Thanks for the clarification on the message handler code, and the message structure recommendation.
It definitely will help me in crafting the ARM/DSP comms.
Regards,
Doug - JC 11:01 AM Software Development: RE: DSP HelloWorld Message Queue Buffer Length
- Doug,
As far as I understand the anLength is really the length of the buffer passed between the DSP and ARM and is likely going to be bigger than your actual message. I agree that the description of the parameter is misleading.
Wh... - I'm modifying the DSP HelloWorld example code from the Wiki site to transfer data types other than strings (see SW Forum message "Data Transfer over DSPLink").
While debugging the transfer of an array of ints, I noticed that in the AR...
09/02/2014
- JC 08:33 AM Software Development: RE: How to probe the fpga_ctrl & fpga_gpio.ko module
- Have you made any progress with this problem?