|Digital Line Level DACs, Digital Crossovers, Equalizers, etc.|
Please consider donating to help us continue to serve you.
Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
||Thread Tools||Search this Thread|
|27th June 2020, 11:38 AM||#1|
Join Date: Jan 2020
USB sound card's EEPROM reading/(re)flashing
I have a simple SA9023 USB-to-Optical/Coax converter.
The story below is not too important though, I would need general understanding first
While trying to use the converter with Raspberry Pi I faced several USB related unstable "miracles", the converter perfectly/stably works with PC though. I suspect the converter EEPROM content is not consistent enough (there are some null string descriptors in there at least).
Maybe there is a chance to fix that, but looks like I just don't understand some basics to move forward. Would be happy if somebody could navigate me a bit.
So some general subjects I would like to understand, rather general than the device related.
Unfortunately I'm newbie with that.
1 A USB device has a chip (SA9023 in my case) and (SPI/I2C) EEPROM. Is there a way to access (read/write) the eeprom via USB. Or it could be only possible via a standalone programmer with a clip connected directly to the eeprom?
I know that some USB devices allow the underlying eeprom programming via USB registers. Sometimes it's briefly documented, but usually not.
Actually almost any USB device has a chip + eeprom, so the eeprom content (initial at least) population should be performed anyhow and it should be technological enough (for manufactures). It's hard to imagine a "man with a clip" in a factory.
Maybe there is just a common approach I'm not aware of. Or it's a vendor/device dependent "zoo"? The datasheets are typically silent at this point.
2 A modern USB device typically has a chip + eeprom. So there is a reason to believe the eeprom stores not data only but code for internal processor as well. It's hard to believe the chips are not universal enough as there is a lot of various devices based on the same chip.
However the datasheets include nothing about the processor, its type, commands set, internal registers, peripheral addressing, ports etc. Could it be it's just too common and well-known? So no information is available unconditionally and I'm just not aware of.
Anyway such firmwares were developed anyhow and (most probably) developed independently from the processor core, So the information should exists somewhere,
Could it be there is just a kind of "8051" processor inside and everybody know that excepting me? It's hard to believe every USB device manufacture creates its own processor to produce the device. Is there something to start reading from?
Thank you in advance
|27th June 2020, 02:35 PM||#2|
Join Date: Jul 2016
Not sure why you are pursuing the above described approach in relation to the RPi performance problem you described. Probably best to assume the USB board design is okay and look at what is going on electrically using an oscilloscope and or high speed logic analyzer.
Regarding processors used in USB controller devices, many are proprietary and may require an NDA with the manufacturer to get information. Some manufacturers won't talk to small companies or individuals. In the above sense information about programming is often hard or impossible to come by. Not only that but processor compiler software may not be free, some may be rather expensive to license.
|27th June 2020, 03:16 PM||#3|
Join Date: Jan 2020
Actually, I’m not trying to solve the current problem only, it could be rather a side effect of the main goal that is attempt to understand the underlying details.
The problem just inspires me to understand. (Is it completely stupid idea?)
I could easily give up the (relatively cheap) USB converter and order a new one,
if it has a hardware/firmware defect. The same is true for Raspberry PI
Moreover I’m starting to realize a possible the problem reason, the device is a (surprisingly) USB 1.1 one, so the Raspberry’s USB hub has to involve Transaction Translator (TT), but it’s a Single-TT entity. So using an intermediate hub is recommended and it really helps. All the rest are Rasp's USB hub firmware bugs probably.
While “dancing” around the above I just found a technical layer I’m not aware of completely and looking for an approach to expand the “horizons”
Obviously I could admit it’s all rather the manufactures “secrets” without a way to go deeper.
I just think if the technology as “chip+eeprom” is so poplar there could be something widely known I would like to know as well.
>processor compiler software may not be free
Obviously that could be, but there is a huge set of gcc based toolchains for almost any physical processor, so just compiling a program should be possible. However without knowledge of peripherals it would be senseless. And I’m hardly going to rebuild the firmware ;-). So the entire architecture is the most curious.
Anyway I’m for the first stage trying to understand “how it works” a bit deeper than “a chip + eeprom + manufacture’s magic to blindly trust”.
Still hope there is something to read/learn to go farther
|Thread Tools||Search this Thread|
|Thread||Thread Starter||Forum||Replies||Last Post|
|how to mix sound from notebook and external sound card and get headphones output||burence73||Headphone Systems||17||29th December 2012 07:58 PM|
|Creative Sound Blaster X-Fi sound card w/upgrade||GOWA||Swap Meet||0||12th August 2012 09:05 PM|
|PC sound card sound chips||kaluchka||Chip Amps||6||20th June 2011 03:48 PM|
|Store real time sound reading in a memory||Progg70||Digital Source||1||29th December 2007 08:48 AM|
|Can your sound card do this?||jackinnj||Everything Else||25||7th November 2005 11:32 PM|
|New To Site?||Need Help?|