XCore Exchange

Hello,
I'm working actively on finishing up my LogicAnalyzer based on XMOS chip (TQFP64).
Well, for the communication with PC, for various reasons, I want to use a PIC24 to act as an USB bridge between the my logic analyzer and PC. I want to use this PIC to update the flash program of the XMOS (on the external EEprom).
The question: I need to put the PIC's SPI pins on the same SPI bus used by the XMOS to access its EEprom. Is there any risk for the XMOS chip? do I need to force it in reset mode (via a pin from PIC) for example? or do I need to use some circuitery to do a logic switch between PIC/XMOS to let one of them access the EEprom?

I sure haven't tried it, but since the SPI pins on the XMOS part are just GPIOs I would think this would be perfectly safe as long as the XS1 isn't driving any of the pins at the time (so do an IN instruction on each -- assuming you're talking about doing the update after the XS1 has booted). On the flip side, obviously you need to be sure that the PIC is tri-stating those lines while the XS1 is booting.

If you're talking about holding the XS1 in reset -- I'm curious about that too. I just did a hardware workaround for a problem caused by the floating GPIOs during boot but I can't find anything in the data sheet that guarantees that the drivers switch off within any particular # of nsec of the RESET L signal's assertion. Seems to be soon enough, but is it really instant?

If you don't mind extra hardware you can add a 2-input mux ('157 etc.) for SS, CLK, and MOSI and yank the EEPROM out from under the XS1 whether it's ready or not.

John Wilson
D Bit

Almost everything tristates its GPIO pin in reset to be on the safe side. So to update the firmware id hold the XMOX chip in reset for a few 100ms before trying to talk to the SPI memory. You can test it for your self by holding a xmos dev board in reset on the XTAG connector and probeing around the 8pin SPI flash with a 1K resistor to ground to see if the pins are driven high or just pulled up high.

When the ROM code has finished reading a boot image from
the SPI, it will turn the SPI ports off, which tristates them. So
you do not need to do IN instructions on them, unless you
have turned them on again.

But. If the image read over SPI is corrupt (checksum does not
match), the ROM code does _not_ turn off the ports, and your
system does not boot of course. So in this case, you _do_ need
some way to force the XCore off the bus, like the reset thing.
Unless you have some other way to boot (JTAG for example),
but then why do you want another MCU to write the SPI :-)

So save yourself some pain, do the reset thing.

Thank you for your answers.
I couldn't find any information about the SPI pins state when processor is in Reset mode :(
I'm affraid I can't do that unless using some kind of hardware multiplexing (4066, 74xx157/158 ... or such ...).

Any info from XMOS staff would be welcome.

Regards

octal wrote:I couldn't find any information about the SPI pins state when processor is in Reset mode :(

From the arch book, 15.2 (port configuration): "A port is initially OFF
with its pins in a high impedance state." That does not really say what
the state is _during_ reset (only after reset), but it's the only thing that
makes sense of course. Measure to be sure. Or file a support ticket.

Yeah that's what got me -- having a port be off after the reset procedure is complete is easy to understand, but they aren't promising that the RESET signal directly clears the driver-enable flip-flop, or whatever it is, on every single I/O pin. If it does then of course the GPIOs disconnect instantly during and after reset, but if not it could be more complicated logic that does it (or even code in a hidden boot ROM) and a lot could happen before the GPIOs get around to tri-stating.

Yeah true you often don't find information on what happens in reset since the chip is meant to be reset quickly instead of being held in it for a long time. But pretty much everything tristates its IO inside of reset since this is the safest state. There might be a switch on a GPIO pin thats connecting it directly to Vdd and driving a 0 on the GPIO would cause a short.

If you want to make sure as i said hold a xmos devboard in reset and probe the pins on the flash chip.