How to disable USB on xCORE-200 Explorer Kit

If you have a simple question and just want an answer.
martinh
Member++
Posts: 19
Joined: Thu Oct 01, 2015 10:55 am

How to disable USB on xCORE-200 Explorer Kit

Post by martinh »

Hello,
 
to use port 16A on tile0 of the xCORE-200 Explorer Kit it is necessary to disable USB (according to the XEF216-512-TQ128 Datasheet).
How would I do that?
Has resistor 43R2 (which connects USB_TUNE to ground) to be removed?
And where can that 'application note on USB for xCORE-200' be found that is mentioned in the datasheet?
 
Regards,
Martin H.


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

Post by mon2 »

Hello Martin. Perhaps can help on some of your questions.

Download this XCORE 200 port map:

https://www.xmos.com/search/content?term=X07017

If you comment out the use of the USB code in your application then the requested P16A on Tile 0 is free for your use. On this subject, it is really wild and different that if you do decide to enable USB on Tile 0 then the P4A, P4B, P4C, P4D ports on Tile 0 are STILL available for your use. Perhaps that option will be suitable for your project. We have confirmed this by enabling USB on Tile 0 and then stepped through each of the 4 bit ports and had control of each of the noted 4 bit port pins.

The USB projects / application notes for use with the XCORE 200 Explorer Kit are posted here:

http://www.xmos.com/support/boards?product=18230

martinh
Member++
Posts: 19
Joined: Thu Oct 01, 2015 10:55 am

Post by martinh »

Hello mon2,

thanks for your reply and also for pointing me to that new XCORE 200 port map.
Its interesting that ports P4A to P4D are still available with USB activated. Good to know for the next project!
For the actual project I need (at least) 2 16-bit-outputs to output 32 bits.
I suppose you did not check if port P16A is available with USB activated, did you? It is using the same pins.

During the last days I had a closer look at port P16A on tile0 and found that I had not considered the QSPI flash.
In "8. Boot Procedure" of xCORE-200_XEF216-512-TQ128-Datasheet_1.6.pdf it is written that "X0D04..X0D07 should be not connected". Does  that mean "must not" be connected?
Supposing I would use port P16A for outputs, wouldn't that cause problems with the QSPI flash?
Also port P1B0 and P1C0 probably cannot be used for other purposes. Is that correct?
I hope I am wrong.

Regards,
Martin H.

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

Post by mon2 »

Hi Martin.

1) If you enable USB on tile0 then P16A is NOT available (as per the XCORE port map X07017 spreadsheet). Not sure if that is what you meant in your wording. Respectively, if you decide to NOT enable USB on tile0, then P16A is available for your project. You are correct that the QSPI interface will interfere with the contiguous block on P16A since some of these pins are used to boot your code from flash.

This QSPI port sharing is true for the XMOS devices with the internal flash and also the external flash devices.

However, read on.

2) These XMOS devices are available with internal flash or you can purchase them without this internal flash (that is what we are doing). If you use the internal flash then you must announce the use of the internal flash using the pull-down 1k resistor. For the same reason, you cannot load down the QSPI flash port pins else you risk to corrupt the data during boot time. We recommend you consider to use an external flash device which will also grant you much flexibility on the density and vendor selection as the flash devices get cheaper and cheaper, etc. In addition to this suggestion, you can apply a small piece of external logic to monitor the SS line and after you are sure the QSPI is not in use, route the same shared QSPI lines to your design. Keeping in mind that the QSPI port pins are just that, port pins which are being manipulated by internal XMOS ROM code, the same port pins can be repurposed after boot or when the QSPI is not in use. Just need to be cautious on the external design but recommending an external FET MUX or similar which are very low cost. The benefit of using a FET mux is that the selector is a no care on which direction the data will flow (A to B or B to A for each port pin).

3) You noted to output 32 bits using 2 of 16 bit ports, why not use the single P32A port on tile0 (but must disable USB on tile0) ? Again, using an external flash + small logic to allow for the sharing of the QSPI port pins, the full P32A port block is available after the XMOS device boots.

4) After you apply the use of the recommended external FET MUX (NXP P/N 74CBTLV3257) or similar, the P1B0 and P1C0 are available for your use. Summary, during QSPI use / boot, the pins mated with the QSPI device should not be loaded down. However, after boot, they are available for your use. Another idea is that could time the XMOS device takes to boot the code and then enable your logic. So the idea is to wait say, 5-10 seconds (silly and very long time to boot from QSPI) and then use the pins of your choice. Upon each power up, an external timer could create the xx second delay and then enable your external logic. The idea of monitoring the SS line is best and should work as noted.

5) CS# on the external / internal flash is active low. When LOW, the QSPI flash is being accessed so the same QSPI lines cannot be used by your project. Respectively, if CS# pin (SS) is HIGH, your MUX can use the same shared port pin lines for your design.

6) Unless you are using tile1, could you use P32A on tile1 ? There is no issue with the QSPI overlap pins on tile1.

Do review if these concepts make sense for your use.

 

martinh
Member++
Posts: 19
Joined: Thu Oct 01, 2015 10:55 am

Post by martinh »

Hi mon2,

1) Sorry, if my wording was not clear. I was not sure if "disable USB" referred to a hardware or software modification. I am not going to use any USB code in the project. So this is clear now.

6) Using port P32A has not been taken into consideration for 2 reasons:
a) This would require a chip with a ball grid array. The design of the board would be more expensive and more complicated.
b) We need to output a huge amount of 32-bit-words. The amount of 256k RAM on one tile is not sufficient. So the memory of both tiles has to be used. The drawback of this output method is that output synchronisation for both ports is very sensitive/critical and is influenced by the clock rate.

4) A FET multiplexer is the solution I would fancy most.

However, as the project is not a very comprehensive one (no USB, no Ethernet) I think I should use port P16B on tile0. So the multiplexer can be neglected. The disadvantage is that it is not possible to have a full xSYS header as X0D40 to X0D4 are used by P16B. But as it was not necessary to use xSCOPE so far I would think that this compromise is acceptable.
If you feel that something basic has not been considered with this solution please let me know.

Thank you very much for your very detailed reply. It helped me a lot to understand things better and make a decision.

Regards,
Martin H.

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

Post by mon2 »

Martin, if you do not plan to use USB nor Ethernet then there is the standard XL216 device you can consider for yet a lower cost.

P/N XL216-512-TQ128 ; no USB & no Ethernet

BGA devices are not complex to work with but do require the proper SMD tools for assembly. There are many good quality PCB shops we can suggest in Asia if you need bare PCBs for your project. Most of the same suppliers will also assemble the PCBs at relatively low costs. Varying on your budget, there are also turnkey PCB designers and assembly houses available. On this note, we are quite nervous on how much we outsource as we have had a number of our designs copied in Asia (without our permission).

Also, QSPI is one option to boot your code but there is also the alternative to use standard SPI which will free up some additional pins used by the Quad SPI interface. The small drawback is the slower time to boot due to the flash access when using standard SPI flash devices.

martinh
Member++
Posts: 19
Joined: Thu Oct 01, 2015 10:55 am

Post by martinh »

Hi mon2,
 
that chip is an interesting alternative and definitely worth considering. Especially as it provides additional 1-bit-ports.
 
Do you happen to know if there are modules with BGA chips available on the market? I am thinking of small PCBs that can be plugged on a bigger PCB. Such modules could make the design of new boards much easier.
 
Regards,
Martin H.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am

Post by mon2 »

Hi Martin. Not aware of such modules but there are 40 pin dip version of XMOS based projects, etc. on this website. Again, not sure if they are commercial ventures but rather open source DIY projects. What would you like to see ? Perhaps we can take on such a design if practical to consider. Are you thinking of a BGA to dip fan-out board with a premounted XMOS device ? If yes, which device ? We are tooled up for assorted XMOS devices for our internal R&D and perhaps we can squeeze in such an adapter but first we must agree to be on the same page on the features. No guarantees but can review internally.

martinh
Member++
Posts: 19
Joined: Thu Oct 01, 2015 10:55 am

Post by martinh »

Hi mon2,

the question was meant to be for projects in the future. For our actual project a TQ128 chip is ok. We can solder it and design the board as well.

What I had on mind was a piggyback pcb equipped with a BGA xCORE-200 device (for instance XE216-512) + power supply that easily could be added to a base pcb. So the customer can put his own circuitry on the base board and simply add (plug-in) the module.
That would make service easier (just swap the piggyback pcb) and the design of the base board as well. It might lower the threshold for designers to use BGA devices.
It's just an idea. I could imagine that there is a market for it.

Regards,
Martin H.

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

Post by mon2 »

Something like this ? Work in progress and welcome all feedback. More details to follow soon.

Image