1) Is it possible to initialize the peripherals on the board from ARM
using CCS? If so, how can it be achieved?
Since you have JTAG access you can do more or less everything. I however
don't know of any GEL-files really useful for Beagle => You have to write
your own GEL-files for doing whatever you want/need peeking and poking all
the relevant registers in all the peripherals. It's a huge task, but it can
be done
2) Is it possible to run a stand alone application on the C64x+ DSP?
Yes - The two cores are as such independent - Except, that the ARM core
needs to take the DSP out of reset. But after this, you can use them
independently in case you want. You of cause need to make sure that only one
core access a given IP block at a time, and that these "external" accesses
are somehow synchronized.
3) The default gel file loaded for the DSP is c64xplus_CrossTrigger.gel.
Does it vary with the type of flash memory on the board?
Giving it a brief check I would say no - Any reason why it should depend on
the flash memory?
But I would want to know if anybody has given this a shot? There is a
need to get this working fast, so right now, I dont have much time for
peeking around....
But I would want to know if anybody has given this a shot?
There is a need to get this working fast, so right now,
I dont have much time for peeking around....
What do you exactly need? Asking if anybody have programmed the IP blocks in
OMAP3 using GEL-files is a pretty broad question - The chip contain 15+
different IP blocks and several thousand registers and the TRM is around
3.500 pages
I have previously personally programmed both SDRC, GPMC, I2C, SPI and HDQ
(plus some more I guess) accesses on other OMAP chips using GEL files, so
it's certainly possible. I unfortunately don't have the scripts available at
hand any longer.
What do you exactly need? Might be you could use some of the functionality
in U-Boot/Linux for doing your tests instead?
But I would want to know if anybody has given this a shot?
There is a need to get this working fast, so right now, I dont have
much time for peeking around....
What do you exactly need? Asking if anybody have programmed the IP
blocks in OMAP3 using GEL-files is a pretty broad question - The chip
contain 15+ different IP blocks and several thousand registers and the
TRM is around 3.500 pages
I have previously personally programmed both SDRC, GPMC, I2C, SPI and
HDQ (plus some more I guess) accesses on other OMAP chips using GEL
files, so it's certainly possible. I unfortunately don't have the
scripts available at hand any longer.
What do you exactly need? Might be you could use some of the
functionality in U-Boot/Linux for doing your tests instead?
But I would want to know if anybody has given this a shot?
There is a need to get this working fast, so right now,
I dont have much time for peeking around....
What do you exactly need? Asking if anybody have programmed the IP blocks in
OMAP3 using GEL-files is a pretty broad question - The chip contain 15+
different IP blocks and several thousand registers and the TRM is around
3.500 pages
I have previously personally programmed both SDRC, GPMC, I2C, SPI and HDQ
(plus some more I guess) accesses on other OMAP chips using GEL files, so
it's certainly possible. I unfortunately don't have the scripts available at
hand any longer.
What do you exactly need? Might be you could use some of the functionality
in U-Boot/Linux for doing your tests instead?
Thanks again for your response Let me first tell you the current
scenario:
I have a Beagle Board (Rev B7) and a BlackHawk JTAG emulator and also
CCS 3.3. When the board is powered up, it stops with a uboot prompt.
Now when I try to connect to ARM using CCS, it throws this error:
Trouble Reading Register:
Error 0x80002004/-1203
Fatal Error during: Register, Control,
The DAP access, address 0x000001E4, has returned a SLAVE error.
GEL: Error while executing OnTargetConnect(): target access failed.
When I went through the GEL file for ARM (omap3530_cortexA.gel), the
OnTargetConnect() function initializes the mDDR Samsung memory. But
Beagle board RevB has Micron 128MB mDDR. And it looks like there is
no other function in the gel to initialize the Micron 128MB mDDR.
A look at the uboot code for Beagle board tells me that it initializes
the SDRC registers which are also initalized by the OnTargetConnect()
function. So should the same configuration be used in the GEL file as
well? And how do we initialize the other peripherals like DSS
(Display SubSystem)?
My second question is, when I remove the gel files for ARM and DSP,
the connection to both of them does not throw any errors. But still
my application on the C64plus DSP gets stuck in a memory issue. So
can we run a standalone application on the DSP without any peripheral
initialization by ARM or is there a way to initialize the peripherals
needed?
I hope you could understand my concerns. Thanks in advance...
Trouble Reading Register:
Error 0x80002004/-1203
Fatal Error during: Register, Control,
The DAP access, address 0x000001E4, has returned a SLAVE error.
GEL: Error while executing OnTargetConnect(): target access failed.
This error is not supposed to happen - Which Service Release of CCS are you
using?
When I went through the GEL file for ARM (omap3530_cortexA.gel), the
OnTargetConnect() function initializes the mDDR Samsung memory. But
Beagle board RevB has Micron 128MB mDDR. And it looks like there is
no other function in the gel to initialize the Micron 128MB mDDR.
Right - Agree
A look at the uboot code for Beagle board tells me that it initializes
the SDRC registers which are also initalized by the OnTargetConnect()
function. So should the same configuration be used in the GEL file as
well?
The GEL files don't need to initialize the SDRC when this is already done by
u-boot running on the ARM core - You can just commend out the code in the
OnTargetConnect()-function - Remember to reload the GEL file after modifying
it (right click at it and select reload). If you don't do this, it will
still use the old version although you modified it...
And how do we initialize the other peripherals like DSS
(Display SubSystem)?
In the exact same way as you would do in a normal C-program.
Start by reading the TRM (spruf98b.pdf) DSS chapter and go on from there...
My second question is, when I remove the gel files for ARM and DSP,
the connection to both of them does not throw any errors. But still
my application on the C64plus DSP gets stuck in a memory issue.
How do you get your application into the memory and release the DSP from
reset in case you don't have any GEL file loaded for the Cortex-A8 giving
you the extra menus in CCS for taking the DSP out of reset?
So can we run a standalone application on the DSP without any peripheral
initialization by ARM or is there a way to initialize the peripherals
needed?
In case you DSP program doesn't depend on any peripherals you should be able
to run it even though you haven't initialized any peripherals (other than
SDRC, which I assume you need?
I am using service release 12. What might be the cause for that
error? The gel file being used is omap3530_cortexA.gel and uboot is
running on the board.
I am using service release 12. What might be the cause for that
error? The gel file being used is omap3530_cortexA.gel and uboot is
running on the board.
Hi Divya,
I have no really bright idea popping at my mind. However make sure you have
the right driver for your JTAG-emulator and that you are using a version
compatible with the USCIF version you are using. At least for the Blackhawk
drivers you normally need to update them hand in hand with the current CCS
Service Release...
Which kind of emulator are you using? - I apologize in case you have already
written this once? I have successfully used both the Blackhawk USB560m and
the Spectrum Digital 560 PCI card.
One other option would be to attach your GEL files in order for me or others
to verify, that the they are identical to the ones we are using...
Best regards - Enjoy your weekend
Søren
PS: I have previously had luck using SR12 - Today I'm using SR13(.1), which
was just recently released...
I am using a BlackHawk USB560m emulator. I dont have the gel file
here at home. Will attach it once I get back to office. I would also
try out service release 13.1 and let you know. Thanks so much.
Instead of using the omap3530_cortex.gel (which comes with CCS 3.3), I
tried using Mistral_Omap35xx_CortexA8.gel (which comes with CCS 4
beta) and now I dont get any error when connecting to the ARM
processor using CCS 3.3. So looks like there is something missing in
the first gel file. I will investigate about it and let you know.
There is an application for DM6437 which I am porting to the DSP on
Beagle board. A process in this application which uses DMA waits
forever never coming out of the wait loop. I guess DMA is not
enabled. Do you have any idea about this?
There is an application for DM6437 which I am porting to the DSP on
Beagle board. A process in this application which uses DMA waits
forever never coming out of the wait loop. I guess DMA is not
enabled. Do you have any idea about this?
Do check the DMA controller differences b/w OMAP3 and DM6437 and if the
changes have been incorporated..
Regards,
Nishanth Menon
When I looked for DMA documents related to OMAP3530, I found only SDMA
docs. And it refers to DMA hardware version 4. Is it different from
the DMA/EDMA version 3 being used in DM6437?
Let me first tell you the current