Project

General

Profile

uPP receiving problem

Added by Silvano Bertoldo over 9 years ago

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 made by 2 bytes.
I use the libraries provided us together with the MDK.
The code compile and the project can be loaded to the DSP using the JTAG connectore without any problem.

Could someone have a look at the code and tell me if something is wrong?
At the moment it seems to be wrong. When I debug it it does not acquire anything from FPGA, even if the signal is present on the dedicated pins.

Any suggestions?

Thanks in advance.

Silvano

main.cpp (2.75 KB) main.cpp

Replies (12)

RE: uPP receiving problem - Added by David Rice over 9 years ago

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

RE: uPP receiving problem - Added by Silvano Bertoldo over 9 years ago

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?

RE: uPP receiving problem - Added by David Rice over 9 years ago

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

RE: uPP receiving problem - Added by Silvano Bertoldo over 9 years ago

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.

RE: uPP receiving problem - Added by David Rice over 9 years ago

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

RE: uPP receiving problem - Added by Silvano Bertoldo over 9 years ago

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

RE: uPP receiving problem - Added by Silvano Bertoldo over 9 years ago

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

RE: uPP receiving problem - Added by David Rice over 9 years ago

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

RE: uPP receiving problem - Added by Jonathan Cormier over 9 years ago

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

RE: uPP receiving problem - Added by Silvano Bertoldo over 9 years ago

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

RE: uPP receiving problem - Added by Silvano Bertoldo over 9 years ago

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...

RE: uPP receiving problem - Added by Gregory Gluszek over 9 years ago

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

    (1-12/12)
    Go to top
    Add picture from clipboard (Maximum size: 1 GB)