XHRA-2HPA-TQ64 - Use UAC1_SEL pin without disrupting SPI?

[smiba]

EDIT: Hey everyone, stop reading here. My conclusion at the end of the topic is WRONG. You can actually use a 3.3k resistor to pull QSPI_D1 up to activate UAC1_SEL. having a pull op resistor does not harm the data as the XMOS chip pulls the data line down with more then 3.3k when it should be low.

Hi, sorry for asking. I feel like its obvious but I can't really figure out if this is a possible configuration:



In this scenario VCC33 is going through a 3.3k resistor and is controlled by a small switch (which will either allow VCC33 to pass through or block).

It just seems like this would screw with the SPI data channels (If UAC1_SEL is high), if I'm not mistaken.

Q1: Is this a possible configuration?

Q2: After the firmware is initialized correctly, will it still require access to the SPI data pins?

Assuming this is not a proper configuration, would an solution be to route GPIO_1 to a transistor going to UAC1_SEL/QSPI_D1 and flash the firmware configuration to set GPIO1 to High on Both USB connect and Disconnect? (Always on, but only after the firmware is initialized, which would indicate there is no more further QSPI communication going on and we can route VCC33 to UAC1_SEL)

English isn't my native language so I hope I wrote it in a way its understood

Much appreciated!

[smiba]

After taking a small break from work I realised I've been indeed a dumbass haha

Of course this is going to disrupt the QSPI communication!
Would my solution still work though? The goal is to implement a switch to move between Audio Class 1.0 and 2.0 (Compatibility)

would an solution be to route GPIO_1 to a transistor going to UAC1_SEL/QSPI_D1 and flash the firmware configuration to set GPIO1 to High on Both USB connect and Disconnect? (Always on, but only after the firmware is initialized, which would indicate there is no more further QSPI communication going on and we can route VCC33 to UAC1_SEL)

[mon2]

Hi. A few comments:

1) Are you writing custom code to use the XHRA-2HPA-TQ64 processor ? If not, believe that this processor has encrypted code supplied by XMOS so the code is a fixed function and cannot be changed.

2) This QSPI pin is only 1 of 4 bits that must work in the same direction. Either all 4 bits of the QSPI are input or all 4 bits of the QSPI pins are output (D0..D3).

3) Any high on this pin would then enable your switch so even a high data value on this bit (from the QSPI flash during code read) can enable the switch. Is that ok ?

4) From our understanding, the QSPI flash memory is read during boot time and the read information is copied to local ram for execution. After the boot is finished, believe you are ok to re-use this port pin - if the code is written to do so. Again, all 4 bits of the QSPI pins must be all in the same direction.

The above are just my general comments on XMOS ports.

=========

Perhaps you can supply more details on your project ?

How will you select Audio Class 1.0 support ?

How will you select Audio Class 2.0 support ?

If you map a logic switch to a port pin, then that port pin will need to toggle HIGH or LOW. How will the end user make this selection ? The code (firmware) must offer this support to toggle the selection pin.

Not fully understanding why this QSPI pin D1 must be used for your switch unless the firmware supports this feature already from XMOS.

[smiba]

First off all thanks for your help :)

1) Are you writing custom code to use the XHRA-2HPA-TQ64 processor ? If not, believe that this processor has encrypted code supplied by XMOS so the code is a fixed function and cannot be changed.

If I'm correct the firmware has a configuration stored in the SPI memory with some basic events and commands to execute. (Check datasheet page 25&26), in this case I can tell the chip to put GPIO1 to high (0xE2) on both USB connect (0x1A) and disconnect (0x1C) (Which will if I'm not mistaken result in having GPIO1 always on)

4) From our understanding, the QSPI flash memory is read during boot time and the read information is copied to local ram for execution. After the boot is finished, believe you are ok to re-use this port pin - if the code is written to do so. Again, all 4 bits of the QSPI pins must be all in the same direction.

Alright thanks, I'll make sure my design takes this into concideration and will wait for the chip to load its firmware before it sets UAC1_SEL to high / put any power on the pin while it still serves as QSPI_D1

Perhaps you can supply more details on your project ?

Its going to be a high quality ('audiophile-grade') USB audio device combined with the WM8741 as DAC.

How will you select Audio Class 1.0 support ?
How will you select Audio Class 2.0 support ?

There will be a switch on the device for easy access, either blocking the current flow (low) or sending VCC33 (high) to UAC1_SEL

If you map a logic switch to a port pin, then that port pin will need to toggle HIGH or LOW. How will the end user make this selection ? The code (firmware) must offer this support to toggle the selection pin.

If I'm not mistaken the datasheet tells me that putting high on this pin will tell the chips default (XMOS provided) firmware to use Audio Class 1.0 instead of 2.0, like I said the user will toggle between the two with a little switch.

Not fully understanding why this QSPI pin D1 must be used for your switch unless the firmware supports this feature already from XMOS.

QSPI_D1 has two fuctions, it serves as QSPI data pin and after initialization it will become UAC1_SEL (alternative function, check datasheet page 7 "Configuration I/O pins")

This all is, if I'm not mistaken.

[mon2]

By order of operation, the ROM code inside this CPU will force the same pin to be in QSPI mode while booting. While booting, you will not have the (USB) control to make the same QSPI pin D1 as an output. The firmware boot cycle should be quite fast since in QSPI mode. The dual purpose of this pin is based on the firmware that is loaded from the QSPI flash memory and copied into local CPU RAM.

After boot, the QSPI pins could, in theory, be used for other purposes. If the firmware permits this change then you are fine to retask the same pin as a switch like you have noted. Please confirm with XMOS if the firmware truly offers this feature but you should be able to check easily by simply checking for the voltage on the QSPI Pin D1 after a boot. Then apply your USB command and see if the QSPI Pin D1 toggles high / low in sync with your USB commands.

Keep in mind that even during boot, your external switch can toggle high / low = switch will be ON / OFF during firmware boot time. Not sure if this can lead to any audible audio noise for the listener.

[smiba]

I think I got it figured out, but I just need to make sure.

Does the XMOS chip stop SCLK (The Clock for the SPI flash chip) after its finished? I'm scared that by putting power on one of the pins that is also connected to the flash chip that I might destroy its firmware or data because it interprets it as commands

Can anyone with an oscilloscope and XMOS chip example board test this?

[smiba]

Maybe I'm thinking too difficult about it,

Why not just have two SPI flash chips? One with the UAC1_ENABLE setting set to USB Audio 2.0 and one with USB Audio 1.0

The price of those flash chips aren't too expensive (especially if you look at the total price list of the components) and it would allow for a very easy to implement solution (The switch controls which chip gets powered up)