X
RSS YouTube LinkedIn Twitter Facebook

Search




Post new topic Reply to topic   [ 8 posts ] 
Author Message
858
PostPosted: Fri May 18, 2012 11:50 pm 
User avatar
XCore Moderator
Joined: Thu Jan 27, 2011 3:30 pm
Posts: 203
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?


Top
Offline Profile View all posts by this user  
 
149
PostPosted: Sat May 19, 2012 5:43 am 
User avatar
Member++
Joined: Fri Oct 28, 2011 10:53 pm
Posts: 31
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


Top
Offline Profile View all posts by this user  
 
1420
PostPosted: Sat May 19, 2012 7:55 am 
User avatar
XCore Moderator
Joined: Thu Dec 10, 2009 10:17 pm
Posts: 332
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.


Top
Offline Profile View all posts by this user  
 
2655
PostPosted: Sat May 19, 2012 8:28 am 
User avatar
XCore Expert
Joined: Sun Jul 11, 2010 1:31 am
Posts: 824
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.


Top
Offline Profile View all posts by this user  
 
858
PostPosted: Sun May 20, 2012 5:05 pm 
User avatar
XCore Moderator
Joined: Thu Jan 27, 2011 3:30 pm
Posts: 203
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


Top
Offline Profile View all posts by this user  
 
2655
PostPosted: Sun May 20, 2012 9:54 pm 
User avatar
XCore Expert
Joined: Sun Jul 11, 2010 1:31 am
Posts: 824
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.


Top
Offline Profile View all posts by this user  
 
149
PostPosted: Mon May 21, 2012 12:34 am 
User avatar
Member++
Joined: Fri Oct 28, 2011 10:53 pm
Posts: 31
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.


Top
Offline Profile View all posts by this user  
 
1420
PostPosted: Mon May 21, 2012 8:20 pm 
User avatar
XCore Moderator
Joined: Thu Dec 10, 2009 10:17 pm
Posts: 332
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.


Top
Offline Profile View all posts by this user  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic   [ 8 posts ] 


Who is online

Users browsing this forum: Google [Bot] and 2 guests



Search for:
Jump to: