FX3 FLAG_A stays low.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
LuCu_4098176
Level 3
Level 3

Hello,

I am using the slave fifo implementation provided with no code changes in what respects the slave fifo.

(only added very little code to implement a few vendor commands to control GPIO lines).

The full application works perfect but sometimes FX3 starts with flag_a low and as a consequence nothing will work afterwards.

The PC aplic at startup reads data to flush all buffers but there no data is available at bulk ep. (actually no data was written to the

slave fifo so there is no reason for the flagA to be low).

This is a somehow rare situation but even so if I reset the FX3 many times I can see this happening a few times.

When this happens the Flag_a actually gets high for about 5us and then goes low and stays there forever.

I am sure that nothing is written to the slave-fifo, as the WE is high all the time, while PCLK has a running clock.

I really wish is to have a way to really reset/initialize the slave fifo to a know initial state.

(on my application I do have a vendor cmd that does a initialization of the FPGA I have connected to the FX3

I would like to add the necessary code lines to be sure I got the slave fifo fully reset too so that I init FPGA and slave-fifo

and stay assured that all is ready to go ).

Is there a programatic way to reset/initialize the slave fifo interface to be sure it gets in the proper state ?

Or is this flag_a low issue a know issue that I can solve somehow ?

Thanks.

Luis C.

0 Likes
1 Solution

Hello Yashwant,

Thanks for you reply.

I took a bit of time to come back as I was actively playing with the board I have under development and reached some conclusions.

(somehow this ends up being related with my other post regarding the reset line and booting from I2C)

The GPIF config was not changed. And actually the FX3 comes up already with flag down even before the I2C boot loading starts and stays there forever. On the software I actually have a counter for PROD and CONS events that keeps being reported on the debug as this was very useful to the development. When this happens there is an error thrown at startup and then no PROD or CONS will ever happen and the flag is stuck.

This unexpected situation only happens right after manual reset and never on a power up reset, even so this is a rare event most of the time it resets ok.

My believe is that this particular situation is not really a bug we need to solve. As far as I could investigate this is something that

comes already messedup from the hardware reset. The important discovery I have made points to multiple edges caused by the the reset done by hand jumper or by a metallic tip on the reset jumper. This unclean reset with several transitions also had put me in trouble with the I2C boot.

While investigating In order to solve the issues on i2c boot by providing a clean reset signal I also stopped to see this behavior.

Power off/on always works fine. A clean reset always works fine.

I guess some additional care should be placed on the reset line if it is supposed to be used by anyone in addition to the power-on reset.

Apart from this reset detail the FX3 is now fully (both software and hardware) functional on my board

lets see if this happens again, hope not.

Regards.

Luis

View solution in original post

0 Likes
3 Replies
YashwantK_46
Moderator
Moderator
Moderator
100 solutions authored 50 solutions authored 50 likes received

Hello Luis,

Please refer to the following KBA: Debugging when DMA Flags do not Work as Expected while Reading Data from FX3 – KBA230545

Can you please let me know if you have made any changes to the GPIF state machine provided with the app note?

After the reset, are you loading the program into FX3's RAM from EEPROM or FLASH or programming it via USB, before checking for FLAGA?

The master should drive the address lines A0:A1 properly so as to select the correct thread and flags corresponding to it.
So, once the master selects the address correctly, only then, the FLAGs would be in the correct state and if the FPGA doesn't select the address correctly, the correct FLAG status won't be reflected.

Also, can you please let me know if the host is reading the data right after that reset of FX3 and re-programming is done?
The FLAGA being low indicates that the DMA buffer is not ready to receive or send any data to the master.

Can you please check the PROD and CONS events and share the UART debug traces with me?

Regards,
Yashwant

Hello Yashwant,

Thanks for you reply.

I took a bit of time to come back as I was actively playing with the board I have under development and reached some conclusions.

(somehow this ends up being related with my other post regarding the reset line and booting from I2C)

The GPIF config was not changed. And actually the FX3 comes up already with flag down even before the I2C boot loading starts and stays there forever. On the software I actually have a counter for PROD and CONS events that keeps being reported on the debug as this was very useful to the development. When this happens there is an error thrown at startup and then no PROD or CONS will ever happen and the flag is stuck.

This unexpected situation only happens right after manual reset and never on a power up reset, even so this is a rare event most of the time it resets ok.

My believe is that this particular situation is not really a bug we need to solve. As far as I could investigate this is something that

comes already messedup from the hardware reset. The important discovery I have made points to multiple edges caused by the the reset done by hand jumper or by a metallic tip on the reset jumper. This unclean reset with several transitions also had put me in trouble with the I2C boot.

While investigating In order to solve the issues on i2c boot by providing a clean reset signal I also stopped to see this behavior.

Power off/on always works fine. A clean reset always works fine.

I guess some additional care should be placed on the reset line if it is supposed to be used by anyone in addition to the power-on reset.

Apart from this reset detail the FX3 is now fully (both software and hardware) functional on my board

lets see if this happens again, hope not.

Regards.

Luis

0 Likes

Hello Luis,

Happy to hear that the issue is resolved.
Thank you for the detailed explanation about the unclean reset transitions and may as well be the debouncing issue as you pointed out.
The link to the other thread: Re: Boot from i2c sometimes default to USB boot

Regards,

Yashwant

0 Likes