Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

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 false. It depends on how your FPGA core is set up....

The rest of your initialization looks good.

You'll also want to carefully evaluate your FPGA outputs. If they are not correct, of course, you won't receive anything.

Dave

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 code is right it should work or not? Does it need some start?

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.

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.

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.

Dave

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.

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, another DMA will be queued up to ensure that there is always a buffer available, and no data will be dropped.

Dave

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 on the initialization of the variables "nBytePerLine" and sometimes steps forward to the while cycle. And that happens without a reasons.
Then, having a look at the registers of uPP, the number of current line of DMA transfer (in UPIS1) is always wrong (never 4096) even if the transfer is terminated. Why?
I also tried to set up different interrupt but nothing change.
I do not know how to solve these problems.
As soon as my colleague in in office I will give you the FPGA code which generates a sequence of 1.

Thanks.

Silvano

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

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 stepping oddly. Perhaps you have optimization on? You might have to talk to TI about that.

Dave

The strange stepping sounds exactly like when optimizations are turned on.

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, maybe about the DSP/BIOS?

Thanks.

Silvano

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.

I would like to ask you the following thing:

luUppcrReg.sRegBits.SOFT = 1;
    luUppcrReg.sRegBits.RTEMU = 1;
    luUppcrReg.sRegBits.FREE = 1;
    luUppcrReg.sRegBits.EN = 1;

In order to debug the software, are the previous bits of the register UPPCR correctly set?
By default the library provide only FREE and EN set, but the user guide said also to RTEMU e SOFT respectively to soft stop periheral during emulation and to control the real time emulation.

Please help me!

I hope it is not a VHDL 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 having issues with the uPP when the debugger was attached so I would recommend trying to run without the debugger if possible and seeing if that causes the problem to go away.

Thanks,
\Greg