04:44 <whitequark> sure, i have a bunch

06:42 <mrec> seems like I'm hitting some silicon bugs and I'm still searching for workarounds :-(

06:42 <mrec> that chip turns out to be a nightmare for the easiest things

06:43 <mrec> the fifo addressing is messing up the fixed programmable flags and returning wrong values

06:44 <mrec> there's a errata but that only targets out transfers but I need in transfers

06:58 <mrec> ok device trashed problem solved temporary at least .. shit cypress

07:11 <Stormwind_mobile> Is this the chip that's inside the saleae(clones)?

07:12 <mrec> yes

07:13 <mrec> it depends what you want to do with it a single fifo is fairly easy to implement

07:13 <mrec> and that one works but I'm running into issues with multiple fifos

07:13 <sorear> (it's also the chip glasgow uses for USB interface, which is why I suggested here)

07:13 <Stormwind_mobile> ktemkin: I used KiCad for the first time this summer to just look at schematics and layout of a project and was already raising a few eyebrows about uninititive UI. I really wonder if they regularly present the program to students or someone who knows another EDA, and check for intuitivity.

07:13 <mrec> interestingly I have one device which works but I don't see any electrical difference

07:14 <mrec> this chip is fairly unreliable when it comes to multi fifos

07:14 <Stormwind_mobile> Different board?

07:15 <mrec> well I cut a trace with the knife and soldered it back in theory there should not be a difference

07:15 <mrec> first I thought it was a firmware issue but now I'm sure it's a silicon bug

07:17 <mrec> the programmable flags are not reset once buffer is available again

07:17 <mrec> if I pump data into the first channel, the data will be transfered properly

07:18 <mrec> if I pump data into the second channel, the data will be transferred properly on the second channel but I cannot enable datachannel 1 independently anymore

07:18 <mrec> now I always need to enable channel 2 in order to get data from channel 1

07:18 <Stormwind_mobile> So identical boards, and one of them works as intended?

07:18 <mrec> if I stop pumping data into the second fifo, and clear the buffers I can get data from channel 1 again

07:19 <mrec> yes but not sure why.. I would have some clarification how the situation can turn out like that why the first fifo has a dependency on the second fifo suddenly

07:20 <mrec> the only difference would be that I have cut a trace and soldered it back.. I had the same issue with the working board before

07:20 <Stormwind_mobile> Different package marking? I geuss the chip gives some kind of id and revision bytes somewhere?

07:20 <mrec> no it's the same

07:21 <mrec> I opened a ticket at cypress they should check that I can't believe that I even have that issue after studying the datasheet in detail

07:21 <Stormwind_mobile> Well, you could subject a non-working board to the same procedure and see if it works afterwards...

07:21 <mrec> there's not even a data corruption on any channel

07:23 <mrec> even if I do that I would not know why, I have cut the ground connection to FIFO_ADR[0] and soldered it back to ground

07:23 <mrec> and the ground connection is solid

07:24 <mrec> I'll assemble one more unit and see that cypress can get on that they should explain what the relation between the fifos is

07:24 <mrec> but I doubt that they know anything since the designers are all gone I guess

07:25 <mrec> muxing things to a single channel and demuxing via software is probably a better way to go with this unreliable part

07:37 <Stormwind_mobile> Some crazy parasitic capacitance impedance mismatch signal integrity shenanigans?

07:38 <mrec> the whole pcb is very small to be honest I'm sick of cypress they're unreliable to me.

07:38 <Stormwind_mobile> Try anyway, if you feel like it.

07:38 <Stormwind_mobile> Reproducibility is really helpful, even if you don't have a clue *what* you are reproducing.

07:38 <mrec> I'll order some ftdi parts

07:39 <Stormwind_mobile> Maybe the board layout brings the chip into some sketchy corner-case state...?

07:39 <mrec> I would not know what I should change on a ground pin that got cut and resoldered on the original PCB

07:40 <mrec> I would not even have an idea why the programmable flags pin is doing so weird

07:41 <mrec> I have tried FLAGA/FLAGB/FLAGD always the same result with the first fifo (after pumping data into the second fifo)

07:42 <mrec> ftdi also has 4 channels

07:45 <mrec> there's an errata as mentioned, https://www.cypress.com/file/114011/download

07:45 <mrec> but it's about OUT Endpoints

08:18 <mrec> will take some time until the ftdi part arrives, guess I'm really better off by using that part

08:19 <mrec> you can read the fx2 datasheet over and over it just doesn't give any hint

09:03 <whitequark> mrec: what you're saying doesn't remotely match my experience. in fact, it is the FTDI parts that have well-known silicon bugs they refuse to fix, Cypress rather doesn't (other than the one they describe)

09:04 <whitequark> but more importantly, what you've described so far is just vague complaints. no code, no schematics, no detailed description of data corruption... how am I supposed to do anything with just that?

09:07 <whitequark> it's certainly not true that "the simplest things don't work on fx2". the only time I've hit any strange issues related to fx2 fifo interface in Glasgow were my error, for not honoring the setup/hold constraints on the fpga; zero issues otherwise. you should stop whining and make a minimal reproducible example, then we can talk

11:13 <Stormwind_mobile> But i thought Glasgow uses fx2?

11:13 <whitequark> yes

11:25 <mrec> whitequark: well the simplest things using FIFOADR..

11:26 <whitequark> sure. those have always worked for me.

11:26 <mrec> the programmable flag status is messed up

11:27 <mrec> the second fifo needs to be cleared completely in order to independently access fifo 1 and that absolutely does not make any sense

11:40 <whitequark> again. you should make a minimal reproducible example. then and only then this discussion would be productive

11:52 <mrec> I crashed the device already, the FX2 story is over for me after debugging a week on this nonsense :-(

11:53 <mrec> fx2 is okay for single fifos, but definitely not ok for multi fifos there are some conditions which are for sure a silicon bug and not specified

11:53 <mrec> PINFLAGSAB=0x64 should be more than enough to report the correct pin status on the corresponding ctl pins

11:54 <mrec> but it doesn't matter if flags of the two quad buffered fifos are moved to other control pins it was the same garbage

11:54 <mrec> certainly it's another issue somewhere but it shouldn't be there at all in the first instance.

11:56 <whitequark> well, it's a bug somewhere in your design, yeah

11:58 <mrec> certainly and it's not documented as I went over and over the documentation and pinouts. But if it's clearly reproducible that fifo one works independently if fifo 2 is cleared shows up that there's something wrong going on inside the FX2

11:59 <whitequark> you have not actually demonstrated a minimal reproducible example. so it's not "clearly reproducible", not to me

11:59 <mrec> well my device is in the trash now because I'm done with the FX2 you're a bit too late now :-(

12:01 <ZirconiumX> So...you joined a channel just to rant about your FX2 code not working, and now you're actively refusing to provide an example so that people can help you.

12:02 <mwk> productive, good use of everyone's time

12:02 <mwk> also helpful to anyone dealing with whatever problem it is that you hit

12:03 <mrec> earlier the unit was still alive

12:03 <ZirconiumX> You mentioned you "crashed" it.

12:04 <mrec> or cracked

12:04 <ZirconiumX> Please don't tell me you are creating e-waste because your code crashed.

12:05 <mrec> well I'm not spending another week on figuring out why the first fifo depends so heavily on the second one

12:05 <mrec> and the device is cracked now.

12:05 <whitequark> mrec: look. fx2 is on-topic. your personal incapability to debug your design isn't. either ask actionable questions or go rant somewhere else, I don't care for listening to any more of that

12:07 <mrec> I agree with that, as I still have no idea why the first fifo fully depends on the second one, and the programmable flags report the wrong status.

12:08 <mrec> and changing decis, or the ctl pins does not change anything.

12:08 <ZirconiumX> ...Did you actually read what she wrote?

12:09 <mrec> well my thing is wrong and I don't have the slightest idea where the problem is and the fifo thing is a standard thing according to the documentation it shouldn't not even be possible to have those issues.

12:09 <ZirconiumX> WQ wrote libfx2 as a chip support package for the FX2, so I'd imagine she's relatively familiar with the hardware

12:09 <mrec> anyway story over the unit is cracked I cannot do further tests anymore

12:09 <ZirconiumX> Here comes the hammer, I think.

12:10 <mrec> the firmware is super small I wonder what someone could do wrong there (of course I have tried any possible setting there)

12:10 <ZirconiumX> mrec: I strongly recommend you shut up.

12:12 <whitequark> what a bizarre interaction

12:12 <mwk> happens

12:12 <ZirconiumX> wq: mind if I borrow that one-liner for any future "users" who join my channels?

12:12 <whitequark> sure? it's not like i invented it

12:14 <daveshah> Pretty sure I had an identical interaction with them over a supposed bug with iCE40 BRAM

12:14 <daveshah> Again, no code or actionable things just claiming everything was broken

12:15 <ZirconiumX> Honestly, from a purely pragmatic PoV, if the firmware was really so small

12:16 <ZirconiumX> Why not post the firmware?

12:20 <whitequark> probably because they wanted to take out their frustration on someone, not to have their design fixed

12:21 <mwk> there's no helping someone who doesn't want to be helped

13:38 <emily> did that person really physically break their hardware because their code was wrong

13:38 <emily> humans are so strange

14:26 <_whitenotifier> [libfx2] jedrzejboczar opened issue #2: cdc-acm example: port disabled by hub - https://git.io/JeEvx

14:30 <_whitenotifier> [libfx2] whitequark commented on issue #2: cdc-acm example: port disabled by hub - https://git.io/JeEfJ

14:31 <Stormwind_mobile> You could call that #ragequit

14:32 <Stormwind_mobile> Well, people have broken things for lesser reasons. O would have suggested they let their anger die down and then take some minutes to write about their thought process and what they did for what reason.

14:33 <Stormwind_mobile> It happens often enough that one can't tell the forest for the trees, especially after banging their head into a particular tree for many hours.

16:00 <_whitenotifier> [libfx2] mithro commented on issue #2: cdc-acm example: port disabled by hub - https://git.io/JeETE

16:00 <_whitenotifier> [libfx2] whitequark commented on issue #2: cdc-acm example: port disabled by hub - https://git.io/JeETg

17:38 <_whitenotifier> [libfx2] jedrzejboczar commented on issue #2: cdc-acm example: port disabled by hub - https://git.io/JeEkx