Pin mapping for XUF208 + MCU on a board vs. flash pins Topic is solved

[Yanava]

Hello folks.

I'm spinning the third prototype revision of a product I'm building - a stereo DAC device based on the XUF208-128-TQ64. I have read through a lot of posts and I think it is OK but, since I'm funding this and I don't want to end up with crap boards, would you mind helping me out checking if this pin mapping has any likelihood of accomplishing what I want to do?

I have the XUF208 TQ64 package and a STM32H7 MCU on the same board. I would like to connect them via I2C. I tried that on my second spin, but didn't really paid attention that you need 1 bit ports to have the XUF as a I2C slave. So I ended up using other pins to implement the communication. On the final spin I want to get this right.

Ideally I would like the STM32 part to be the master of the I2C bus, which the XUF part would be a slave. On the bus we have:

• STM32H7MCU (master)
  XUF208 (slave)
  DAC (slace)
  EEPROM device for storing volume levels, board info
  (optional) PLL device, which is now on a separate dedicated I2C with XUF part to avoid timing issues in sample rate changes

I'm attaching the schematic for the XMOS bit, which is the part that I need help with. What I want to avoid having some pin to be used by the internal flash and mess up with my intended control scheme. I have already validated that my 3.3V and 1.0V sequencing is correct, the product is actually working on my desk right now. I just want to tidy it up for cleaner firmware on my end.

Another question on my optional part above: can the PLL device be wired to the MCU or do you really have to change the clocks inside the XMOS function that is called when the sample rate changes?

Finally: can this part handle both USB Audio and SPDIF RX? Not at the same time but as separate inputs. Right now I'm doing SPDIF on the MCU because I felt not very confident with the amount of CPU resources available to implement SPDIF RX.

Thanks!

[mon2]

Hi. Not an audio developer but play one on this user forum so need to ask...

1) your DAC is the slave and the STM32 is the I2C master? Is this correct? Would have thought that you want to have the DAC as the slave and XMOS CPU as the master. Is that not the purpose of the XMOS CPU to be in the design in the first place?

2) On your PLL question, why not do a CYA (cover-your-a**) and allow for zero ohm resistors to strap to the STM32 and another pair to the XMOS CPU. This way, the same (final?) PCB can service either method as you experiment.

3) You wish to use the following port pins on the XU208 TQ64 package for your I2C slave function?

X0D00 - I2C_SDA
X0D11 - I2C_SCL

These are both 1-bit ports so you should have the freedom to do this. Be sure to apply the mandatory I2C pull-up resistors on these I2C lines. Believe that XMOS has an appnote on how to build an I2C slave somewhere on their website.

found it:
https://www.xmos.ai/file/an00157-how-to ... ry-readme/

xmos_i2c.pdf

4) The following is a helpful tool:

https://www.xmos.ai/file/xcore-200-devices-portmap/

[Yanava]

Hello, mon2!

Deeply appreciate your contribution - you helped me a lot!!! Onto your points:

1) The STM32 is the master because it handles volume changes from the front painel IO and I'd rather implement simple communication between XMOS and STM32 about PCM modes than having the volume changes to be programmed by the XMOS chip (which will consume cores which I don't know if I will have on the device). So, the STM32 talks to XMOS to figure audio changes (DSD vs. PCM, sample rate, bit depth, etc) and then does all the configuration.

2) I ended up doing exactly that. I actually strapped the port going to the PLL to the STM32 as well, so now I can do either STM32 to PLL and have the XMOS just floating there or I can have this port as the main communication path between the STM32 and the XMOS if the other 1 bit port fails. Never heard of the CYA expression, will thoroughly use it in several life occasions.

3) Yes, that's exactly what's intended. The pull ups for this particular line are on the MCU sheet, so we should be good!

4) Whoa, that's VERY useful!!!!

I'm now confident my design will not see another spin, at least not from the XMOS side!

Thank you so much!

Best regards.