XK-AUDIO-216-MC-AB ADC protection and MIDI

Technical discussions related to any XMOS development kit or reference design. Eg XK-1A, sliceKIT, etc.
Post Reply
hohoho
Member
Posts: 9
Joined: Tue Jun 02, 2020 3:40 pm

XK-AUDIO-216-MC-AB ADC protection and MIDI

Post by hohoho »

Hi,

I've got XK-AUDIO-216-MC-AB and I have a couple of questions for which I can't find answers.

First one is the hardware question. There are 8 chips marked 59KRV722 on each ADC channel. What are they? I couldn’t find any info on them, but the question is not about these chips per se — do the line inputs have some sort of clippers to prevent the ADC damage? I mean I have a preamp which uses INA217 and it is capable of outputting more than the Cirrus Logic ADC can handle. Is there some built-in protection from that or should I take care about limiting the input level myself?

The second one is about the overall user experience. There is a bunch documents on the XMOS site, but I couldn't find a beginner's guide. And in the software download for XK-AUDIO-216-MC-AB I see a bunch of source code which doesn't really answer my first simple question about MIDI. When I connect the board to my computer via USB, I see 10 input channels and 10 output channels (8 analogue and 2 SPDIF), but I don't see MIDI. I don't need SPDIF, but I need MIDI. What are the steps to enable it?

I'm pretty sure there should be a practical beginners guide somewhere, I have likely just not found it yet...

Thanks.


User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

hohoho
Member
Posts: 9
Joined: Tue Jun 02, 2020 3:40 pm

Post by hohoho »

Thanks!

I've found the schematics. As far as I understand, those chips are LMV722 unity gain op-amps which means there is no built-in overvoltage protection and I need to add some kind of clippers myself. Is that correct?

As for the second part, as far as I now understand, I need to get xTIMEcomposer, then build the new firmware from the provided sources and flash it to the board. Is that correct? Will try. I suppose my main source of confusion is that I didn't expect to build a custom firmware to have the thing working.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi. Personally not an audio developer but correct on the protection. This holds true for any such reference design. Be sure to inspect and apply all levels of protection to keep the end product from an early death while out in the field. Do apply proper USB ESD and surge protection for the VBUS rail - very important! On this note, be sure to insert methods to reflash the firmware, if you should have faults with the firmware - many such audio products are being bricked through field upgrades and have to be returned to the manufacturer for a fix. Not friendly.

Correct on the audio compiling - the source code is available on the forums and xmos.com parent website. Full details are posted by XMOS on how to proceed and target devices like the XU208.

Guessing that the firmware is already installed on the kit you have sourced but not sure of this. Either way, you are most likely going to tweak the end product with your choice of DAC, etc. so the source code will change for your project.

Before making a PCB - post your schematic for a quick review.

Post back if you have issues - there are many audio and XMOS developers on this forum.
hohoho
Member
Posts: 9
Joined: Tue Jun 02, 2020 3:40 pm

Post by hohoho »

What do you mean by «insert methods to reflash the firmware»?

I've found a project named app_usb_aud_xk_216_mc in the software downloads. I'm assuming it's the source code of that particular XK-AUDIO-216-MC-AB firmware. There is a number of configurations in the Makefile there. I've added the following lines to the Makefile (just copy-pasted and tweaked one of the existing targets):

Code: Select all

XCC_FLAGS_2i8o8mxxxxx = $(BUILD_FLAGS) -DMIDI=1 -DSPDIF_TX=0
INCLUDE_ONLY_IN_2i8o8mxxxxx =
It's appeared in the list under the Build button in xTIMEcomposer and it seems to build fine. Will try to flash it, but the «insert methods» thing makes me wondering if I'm missing something.

As for the PCB, at this point I'm not going to make a custom PCB. For my project I need a USB sound card with 8 analogue channels in, 8 channels out and MIDI. That kit by itself seems to be a good solution for me.

Thanks for the clarifications!
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi. Yes, my poor explanation...

1) The firmware you will write / compile and ship with your product is stored inside the SPI flash device. If you purchase the XUF version of the CPU the "F" means the flash memory is INSIDE the CPU. If the "F" is missing in the p/n, the flash device is EXTERNAL to the CPU.

2) Regardless, you need a method to upload your firmware from the host PC onto this target IC. You can do this today using the external XTAG3 tool (aka JTAG) and the kit you are currently using for development. Once you are in production - how to do this on the assembly line? There are some documents posted from XMOS but in short, you need a SPI master device to apply the proper signals onto this target flash memory to upload your code before shipping. Once viable method is to #RESET = LOW to park the CPU -> then use an external SPI flash programmer to access the flash lines and upload your code.

3) My comment on the "insert" is how will the end user do the same - without these exotic tools? Currently working on some cases with other audio manufacturers where they left no access to such tools - their audio widgets are now world wide - the client is in a semi-bricked state for the firmware - how to correct the flash image so they can be operational? The vendor, if they even response to such cases, wants the broken widget returned back to them in China (SMSL). M-Audio ignored the issue when it was raised. M-Audio has serious in-rush current issues with their broken designs. Clients are reporting the CPU was so hot to the touch that they were almost burnt. The only resolution is to replace the damaged XMOS CPU which is a nasty process - even if TQFP package but with a metal belly. Nothing but fun. Then the firmware must be restored onto this virgin XMOS CPU.

Before building any such product, explore every angle on how to fix these corner cases. One thought is to apply an external MUX to steer all such lines to another perhaps USB HID model SPI controller (FTDI, Silabs or similar) -> then even if the flash was erased out in the field, the end customer could press some pin-hole button to make use of the same USB cable on your box to access this flash ONLY -> upload the encrypted flash firmware (if you wish to encrypt - this AES encryption is documented on the XMOS website as well) -> allow for the product to run normally, once again.

Another is to perhaps include 2 such flash devices but keep on in reserve to possibly fix the other.

Short answer, what if the flash device is corrupted - how will the end user fix the issue without access to XTAG3 / JTAG / DFU that is now broken? Ideally without opening up your widget.

Hope this is more clear.
hohoho
Member
Posts: 9
Joined: Tue Jun 02, 2020 3:40 pm

Post by hohoho »

Thanks. I'm a simple do-it-yourselfer. My goal is just one device for personal use (maybe two to have a backup one if something goes wrong). So, mass production is nowhere on my horizon :). But your answer makes it clear why an additional thing called XTAG was coming in my XK-AUDIO-216-MC-AB package.

Going back to clipping the signal, I might actually be wrong. These op-amps before the ADC seem to be exactly the things to protect it (at least I've found an article which explains the op-amp clipper: https://www.electronicdesign.com/techno ... rotect-adc).

So, seems like I just need to reflash it for MIDI and my project has a complete solution for audio IO.
hohoho
Member
Posts: 9
Joined: Tue Jun 02, 2020 3:40 pm

Post by hohoho »

Just if someone will have a similar question, I've got a response from XMOS that those op-amps are for the buffering and they don't provide overvoltage protection. So, I need to add that protection myself.

On the positive side, I've managed to reflash my board for 8 channels + MIDI.
Post Reply