whitequark[cis] changed the topic of #glasgow to: https://glasgow-embedded.org · digital interface explorer · https://www.crowdsupply.com/1bitsquared/glasgow · code https://github.com/GlasgowEmbedded/glasgow · logs https://libera.irclog.whitequark.org/glasgow · matrix #glasgow-interface-explorer:matrix.org · discord https://1bitsquared.com/pages/chat
jstein has quit [Ping timeout: 272 seconds]
Guest31 has joined #glasgow
<Guest31> I got my device a few months ago and am finally bringing it up
<Guest31> I got this error: E: g.cli: FPGA health check failed; if you are using a newly manufactured device, ask the vendor of the device for return and replacement, else ask for support on community channels
<Guest31> is this a case of firmware update required or is my FPGA cooked?
<whitequark[cis]> if you've never powered it on before, that counts as a "newly manufactured device"
<whitequark[cis]> (come to think of it, that may not've been the best phrasing...)
<Guest31> so I should contact indiegogo?
<whitequark[cis]> wait, indiegogo?
<whitequark[cis]> where did you buy one?
<Guest31> crowdsupply
<Guest31> whichever backer thing
<Guest31> sorry
<whitequark[cis]> crowdsupply, yeah. crowdsupply orders are fulfilled by 1bitsquared
<Guest31> I thought there was some kind of firmware update process I had to do?
<Guest31> but can't find reference in the docs
<Guest31> but I guess that's not going to help in this case?
<Guest31> I got it a while ago :(
<whitequark[cis]> no
<Guest31> btw I'm trying to use this to write an EEPROM I wrote with libfx2, breaking the USB enumeration
<Guest31> lol
<whitequark[cis]> oh, right
<whitequark[cis]> you can do this without
<Guest31> oh?
<Guest31> I GTG, back in 1h
<whitequark[cis]> just short the EEPROM pins and plug the fx2 into USB
<Guest31> sorry!
<Guest31> I tried that..
<whitequark[cis]> it should enumerate
<whitequark[cis]> fairly sure you have the wrong pins or something
<whitequark[cis]> that or something else goes wrong. these things are basically impossible to brick, other than by physically destroying
Guest31 has quit [Ping timeout: 240 seconds]
<duskwuff[m]> for clarity, do you mean the FX2 in the Glasgow or a different one?
<whitequark[cis]> they left
joshua_ has quit [Ping timeout: 252 seconds]
joshua_ has joined #glasgow
Guest31 has joined #glasgow
<Guest31> whitequark[cis] thank you
<Guest31> I will try a shorter path to ground?
<Guest31> As for the Glasgow, do I return the case as well or just the board? Is this a known manufacturing error?
<Guest31> the fx2 thing is weird, I was able to get it to not boot from the EEPROM but it didn't show up in the USB device list after.
<Guest31> I'll try again
redstarcomrade has joined #glasgow
Guest31 has quit [Quit: Client closed]
Guest31 has joined #glasgow
MyNetAz has quit [Remote host closed the connection]
MyNetAz has joined #glasgow
Guest31 has quit [Quit: Client closed]
smeding has quit [Quit: Lost terminal]
smeding has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
GNUmoon has joined #glasgow
jstein has joined #glasgow
opticron has quit [Read error: Connection reset by peer]
opticron has joined #glasgow
MyNetAz has quit [Remote host closed the connection]
MyNetAz has joined #glasgow
alluring_parrot_ has quit [Quit: Idle timeout reached: 172800s]
FFY00_ has joined #glasgow
FFY00 has quit [Ping timeout: 252 seconds]
Artea has quit [Quit: ZNC 1.9.1 - https://znc.in]
MyNetAz has quit [Remote host closed the connection]
MyNetAz has joined #glasgow
jstein has quit [Ping timeout: 244 seconds]
Artea has joined #glasgow
tec4 has quit [Quit: bye!]
tec4 has joined #glasgow
jstein has joined #glasgow
<esden[m]> The issue is usually caused by a soldering issue around the 1v2 voltage regulator. You can contact us via info@1bitsquared.com we can take it from there.
Guest31 has joined #glasgow
<Guest31> Sorry, I don't have a bouncer set up.
<Guest31> The EZUSB is on a development board from another company
<esden> Guest31: you can also join on Matrix and Discord, all of those are bridged together.
<Guest31> oh ok, will do that
<esden> While you were away I said: The issue is usually caused by a soldering issue around the 1v2 voltage regulator. You can contact us via info@1bitsquared.com we can take it from there.
<Guest31> cool, just emailed there
urja has quit [Read error: Connection reset by peer]
urja has joined #glasgow
icanc[m] has quit [Quit: Idle timeout reached: 172800s]
mjmdavis[m] has joined #glasgow
<mjmdavis[m]> esden: I'm Guest31. Thanks for the email. From what I can see the 1V2 looks ok but the 3V3 looks starved
Guest31 has quit [Quit: Client closed]
<mjmdavis[m]> mjmdavis[m]: I guess they all look a bit starved.
Guest50 has joined #glasgow
<mjmdavis[m]> <mjmdavis[m]> "I guess they all look a bit..." <- solder stencil issue?
Guest50 has quit [Client Quit]
alluring_parrot_ has joined #glasgow
<alluring_parrot_> Is it possible for an applet to use pins from port A and port B?
<alluring_parrot_> Me again 🙃
<alluring_parrot_> I had a look to the GitHub issues, but I did not find something on the topic
<whitequark[cis]> yes
<whitequark[cis]> if you pass something like --port AB (which is the default), then pins 0..7 are A0..A7 and pins 8..15 are B0..B7
<alluring_parrot_> That simple
galibert[m] has joined #glasgow
<galibert[m]> Can the applet tell that it’s port AB and not have to pass it? For when you do something custom
<whitequark[cis]> I don't understand the question
<whitequark[cis]> if you're driving the FPGA pins directly then you're on your own and the framework won't help you at all (which is also why I won't accept such applets upstream)
<whitequark[cis]> fortunately, with Amaranth 0.5 IO, you can build complex things like DDR I/O while abstracting over exactly which pin you're using
da_lambda[m] has quit [Quit: Idle timeout reached: 172800s]
sigstoat[m] has quit [Quit: Idle timeout reached: 172800s]
MyNetAz has quit [Remote host closed the connection]
MyNetAz has joined #glasgow
MyNetAz has quit [Remote host closed the connection]
MyNetAz has joined #glasgow
<mjmdavis[m]> Catherine: I realise this is probably beyond the scope of supporting libfx2 however, do you know why grounding SCL and SDA on the EEPROM might lead to some weird behaviour?
<mjmdavis[m]> I can stop the fx2 from booting from EEPROM but it's still not showing up on USB.
<whitequark[cis]> oh, use the address pins
<whitequark[cis]> not the scl/sda pins (if you do that it will just wait forever for the contention to clear)
wiebel[m] has joined #glasgow
<wiebel[m]> alluring_parrot_85382: memory-floppy is a good example as it uses all available pins, A and B.
<mjmdavis[m]> I guess that I have to desolder A0?
<mjmdavis[m]> since no resistor?
<whitequark[cis]> yeah you'll need to either cut some traces or pins or desolder the chip
<mjmdavis[m]> jeez
<mjmdavis[m]> Why they not make dev board easy to hack for some other purpose?
<whitequark[cis]> bad choiced
<whitequark[cis]> * bad choiced
<whitequark[cis]> * bad choices
tomkeddie[m] has joined #glasgow
<tomkeddie[m]> The design is some years old now but your input would have been welcome at the time.
<mjmdavis[m]> lol, this is a dev board from AD, nothing to do with this project
<mjmdavis[m]> however, you make a good point :0
jstein has quit [Ping timeout: 244 seconds]
<mjmdavis[m]> <whitequark[cis]> "yeah you'll need to either cut..." <- <3 this worked
<mjmdavis[m]> mjmdavis[m]: thank you!
<whitequark[cis]> mjmdavis[m]: the FX2 has no internal memory
<mjmdavis[m]> whitequark[cis]: I thought I could write a program over USB?
<mjmdavis[m]> mjmdavis[m]: to RAM
<whitequark[cis]> mjmdavis[m]: oh
<whitequark[cis]> whitequark[cis]: yeah
<mjmdavis[m]> <whitequark[cis]> "yeah" <- Is there a way to get it to run my program at boot but also be reflashable over usb?
<mjmdavis[m]> mjmdavis[m]: Can I program boot-uf2-dfu onto the EEPROM?
<whitequark[cis]> <mjmdavis[m]> "Can I program boot-uf2-dfu..." <- it's always reflashable over USB
<whitequark[cis]> whitequark[cis]: the A0 request used for code update cannot be disabled
<whitequark[cis]> s/update/upload/
<mjmdavis[m]> whitequark[cis]: Why could I not flash it when I had bad firmware? Because I didn’t initialise the USB hardware?
<whitequark[cis]> mjmdavis[m]: because you prevented it from enumerating at boot (or perhaps because the firmware was causing it to drop off the bus)
<whitequark[cis]> whitequark[cis]: if it's on the bus, it can be reprogrammed
<mjmdavis[m]> whitequark[cis]: if I don't have a while loop in main will it drop off the bus?
<mjmdavis[m]> mjmdavis[m]: I mean, my goal is to have it write these settings at boot but also be reflashable over usb
<mjmdavis[m]> mjmdavis[m]: so... Just adding my write_settings to the cypress bootloader would work?
<whitequark[cis]> mjmdavis[m]: I honestly have no idea. I also really don't like using threads in Element because of how fucking awful the notification model is
<whitequark[cis]> whitequark[cis]: if I could disable them I would
<mjmdavis[m]> Catherine: is this better :)
<whitequark[cis]> yeah
<whitequark[cis]> now I can tell which window demands my attention instead of getting anxious because I can't tell
<mjmdavis[m]> I guess I'll try installing the cypress bootloader to eeprom with some custom code that runs at init.
<mjmdavis[m]> Does the glasgow have any firmware in eeprom or just enumerates at boot?
<mjmdavis[m]> and transfers over on demand
<whitequark[cis]> I don't think you need any code so long as you don't specifically fall off the bus
<whitequark[cis]> glasgow offers both as options
<mjmdavis[m]> well, I need to write_settings at every power on even if a USB host is not present
<mjmdavis[m]> I guess I have no idea why the firmware that was on there was preventing enumeration
<whitequark[cis]> I have absolutely no idea what's going on in your firmware
<whitequark[cis]> you really should trace it line by line to figure out why it's problematic
<whitequark[cis]> usually main does not return in embedded device firmwar
<whitequark[cis]> s//`/, s//`/, s/firmwar/firmware/
<mjmdavis[m]> The weird thing is that if I run this, the bytes I want are programmed into the target chip. However USB doesn't work.
<mjmdavis[m]> Not your job to help me so I get it if you have other priorities now.
<mjmdavis[m]> I do appreciate the help!
<whitequark[cis]> it might be related to a bit in EEPROM in the header
<whitequark[cis]> fx2tool program --disconnect sets that
<mjmdavis[m]> c2 b4 04 13 86 00 00 00
<mjmdavis[m]> * ````
<mjmdavis[m]> c2 b4 04 13 86 00 00 00
<mjmdavis[m]> ````
<mjmdavis[m]> first 8 eeprom bytes
<mjmdavis[m]> I don't use the --disconnect flag when programming, are you saying I should?
<mjmdavis[m]> fx2tool program -f ./enable-freqout.ihex is how I program
<mjmdavis[m]> (sorry, getting used to Element)
<whitequark[cis]> if you change that to c0 things might start working
<whitequark[cis]> fx2tool program doesn't change that flag, so if it was set, it will remain set
<whitequark[cis]> as far as i recall
<mjmdavis[m]> but doesn't that prevent the code on the EEPROM from executing?
<whitequark[cis]> actually wait
<whitequark[cis]> yeah sorry, I misremembered
<whitequark[cis]> the --disconnect flag is actually not in the section you posted
MyNetAz has quit [Remote host closed the connection]
<whitequark[cis]> or, hm
<whitequark[cis]> you know what, forget it, i'm too tired to read hexdumps
<whitequark[cis]> ignore everything i've said, i can't count to eight
<mjmdavis[m]> haha
<mjmdavis[m]> mathematicians and software people can't count
<mjmdavis[m]> it is known
<whitequark[cis]> no, i just have chronic pain so severe that twice a day (as the painkillers wear off) i get a serious enough cognitive deficit i basically can't work
<whitequark[cis]> and i took them a hour ago, i think
<mjmdavis[m]> :( sorry to hear that
<duskwuff[m]> I've got a FX2 dev board around here somewhere and nothing better to do, I can take a stab at it
<mjmdavis[m]> FWIW I am a great admirer of your work!
<duskwuff[m]> obviously it doesn't have the ADF4351 but that seems nonessential
<whitequark[cis]> i'm glad you find it useful
<whitequark[cis]> i don't mind helping people but it's just not feasible for like a three hour interval twice a day (and you got unlucky)
<mjmdavis[m]> got it
<mjmdavis[m]> thank you
<whitequark[cis]> the really annoying part is that (as with sleep deprivation) your ability to judge your cognitive deficit is impacted per the cognitive deficit
<mjmdavis[m]> maybe it's the configuration byte DISCON bit?
<whitequark[cis]> that's what I was trying to locate in the hexdump
<whitequark[cis]> but it's the byte 7 and it's zero
<mjmdavis[m]> I feel like I'm losing my mind a few times each year. Then I manage to write some decent code and I feel better about myself.
MyNetAz has joined #glasgow
<whitequark[cis]> maybe the firmware ends up in a bootloop or something
<whitequark[cis]> try explicitly setting or clearing _DISCON in the right register (what was it, USBCS?)
<mjmdavis[m]> I traced the wires and it only wrote once
<mjmdavis[m]> will try
<whitequark[cis]> right, okay
<mjmdavis[m]> ok, so I jammed my serial writes into the boot-cypress command and everything seems to work
<mjmdavis[m]> s//`/, s//`/, s/command/firmware/
<whitequark[cis]> yeah
<mjmdavis[m]> ok, no, it seems you really need the whole boot cypress thing to get it to behave
<mjmdavis[m]> I guess my problem is solved.
<mjmdavis[m]> The rest is academic curiosity as to how the thing works.
<whitequark[cis]> perfect, glad you could get it working
<mjmdavis[m]> thanks very much
<mjmdavis[m]> I look forward to playing with the Glasgow when I get mine fixed!