cancel
Showing results for 
Search instead for 
Did you mean: 

USB Superspeed Peripherals

New Contributor

Hi

I have some problems with driving address lines through DR_ADDR in GPIF state machine, in combination with a DMA callback.

I built an image sensor interface based on a modified AN75779 example, with one single thread (THREAD0) DMAconfig type manual with 2 buffers and a callback function for DATA grabbing and again one single thread (THREAD2) DMAconfig type manual_out with 2 buffers and a callback function for driving ADDRESS lines.

I ultimately want to use the address lines for writing data from FX3 memory to an external memory through a dma callback. For now I want to just be able to drive address lines with (random) data while the video runs.

The GPIF interface is Master, Synchronous, Internal Clock, 8 pin data bus, 4 pin address bus.

The image sensor data grabbing works correctly and I get live video from the sensor. The address driving does not work continiously, it allows me to drive only one DMA buffer to the address lines, through a buffer commit in the initialization phase, not through the subsequent address DMA callback function.

A few questions I have:

- I noticed with the logic analyzer that despite the 4 pin wide Address bus defined in GPIF interface definition, the FX3 actually seems to drive 8 address pins in this mode. I see 8 address pins toggling. Why is that? Can the 4 extra Address pins be disabled in this mode?

- How does the Address DMA buffer map to the Address pins?

It looks like despite the 4 address pins configuration, each DR_ADDR action in the state machine takes 3 bytes from the associated DMA buffer, as if it were driving 24 address pins...

- I see the address lines toggling on the logic analyzer only for the very first address DMA buffer that I commit in the initialization phase. The video keeps running normally. The debug interface shows that the address DMA callback is succesfully called after the first adddress consumer event. It also shows that the dmachannelgetbuffer and dmachannelcommitbuffer are executed successfully inside the first call of the callback. However, I do not see the effect of that very first callback execution on the address pins. Also the callback is executed only once, suggesting that the address lines do not consume the buffer that is committed through the callback. What could be the reason(s) for that?

Thanks in advance for any help

0 Likes
Reply
1 Solution
Moderator
Moderator

Hi Sander,

Sander Gierkink wrote:

I now have data input on thread0 and address out on thread1

>> As shown in the attached pdf, if you want to use both data and address bus both then please configure the address bus to only either 8/ 16/ 24 (which of these three are available depends on the usage of data bus and control signals). For ex: If 32 bit data bus is chosen and address bus width is 16, GPIF designer tool would throw error mentioning that only 8 lines are available for address in that configuration)

In your firmware, when you commit a buffer to Thread 1, then only when all the buffer content is driven out of address bus (using DR_ADDR action in GPIF state machine), CONS event is received in the dma callback - (as you might know already, since the channel for driving address buffer is MANUAL_OUT PROD event will not be there). But before you receive CyFxAddressDmaCallback() you can successfully commit two buffers as your buffer count is 2. And subsequent commits are to be made when you get CONS events.

I think the reason for incorrect response on address pins when you did commit buffer in CyFxAddressDmaCallback() may be because of 4 bit address line choice.

Regards,

Hemanth

Hemanth

View solution in original post

0 Likes
Reply
4 Replies
Moderator
Moderator

Hello,

Can you please share the changes that you made in the GPIF II designer?

Please provide the snapshots of the changes if possible.

if possible, please provide your firmware as well so that we can review the changes that you made to the firmware.

Regards,
Yashwant

0 Likes
Reply
New Contributor

Hi Yashwant

Thanks for your reply.

Please find attached some screenshots of the state machine and code.

I now have data input on thread0 and address out on thread1

Let me know if this helps,

Bets regards

Sander

0 Likes
Reply
Moderator
Moderator

Hi Sander,

I see that you want to send the data out through the GPIF interface. For that you are using the address pins.

But please note that when you commit data to the P-Port socket from CPU, the data will be sent out on the GPIF data bus (in your case GPIO [0:7]). The address pins are used if any memory controller is interfaced/ if there is any choice is to be made on the interfaced controller (may be in an FPGA) in order to choose a data path.

You can refer to below thread where one of our examples is modified to make a channel from CPU to P-Port

FX3 CPU to Parallel Port Socket DMA Operation-Manual Out/In

Regards,

Hemanth

Hemanth
0 Likes
Reply
Moderator
Moderator

Hi Sander,

Sander Gierkink wrote:

I now have data input on thread0 and address out on thread1

>> As shown in the attached pdf, if you want to use both data and address bus both then please configure the address bus to only either 8/ 16/ 24 (which of these three are available depends on the usage of data bus and control signals). For ex: If 32 bit data bus is chosen and address bus width is 16, GPIF designer tool would throw error mentioning that only 8 lines are available for address in that configuration)

In your firmware, when you commit a buffer to Thread 1, then only when all the buffer content is driven out of address bus (using DR_ADDR action in GPIF state machine), CONS event is received in the dma callback - (as you might know already, since the channel for driving address buffer is MANUAL_OUT PROD event will not be there). But before you receive CyFxAddressDmaCallback() you can successfully commit two buffers as your buffer count is 2. And subsequent commits are to be made when you get CONS events.

I think the reason for incorrect response on address pins when you did commit buffer in CyFxAddressDmaCallback() may be because of 4 bit address line choice.

Regards,

Hemanth

Hemanth

View solution in original post

0 Likes
Reply