U4 chip is forcing SPI_DOUT line to high Z state when WIFI_EN line goes HIGH to turn CC3000 on. SPI_DOUT line supposed to be in high Z mode when WIFI_EN line is in LOW state and CC3000 is in OFF mode.
Do you mean U2 (the STM32 microcontroller) instead of U4? Also I don’t see how U2 would communicate to the WiFi via SPI_DOUT if it was high Z.
Billions of bilious, blue, blistering barnacles!
No, I mean that tiny 5 pin 3 state chip, where SPI_DOUT ends from the CC3000 to prevent collapsing with the data out pin in the serial memory chip. I think that SPI_CE line was meant to be connected to the U4 /OE pin. It is not wise to turn whole CC3000 to OFF state to only to have communication access from the MPU to serial memory chip. It takes close to 100 ms to turn CC3000 back to ON state.
@pulsar yeah the net name was suppose to be WIFI_CS and not WIFI_EN on the buffer chip. I have made the necessary changes to the schematic and the PCB. Thanks once again!
Hmm, we must not be talking about the Spark Core itself but one of the shields? I am like way confused Sorry.
@BDub we are talking about the Spark Core on the dev branch. We recently added a buffer there.
Is the buffer needed? If the WIFI_CS is inactive (H) I would expect the CC3000 to tri-state it’s SPI_DOUT (with an internal pull UP). Is there an issue with the CC3000? Did you folks see a contention?
The buffer is necessary because the CC3000 doesn’t tri-state. We never ran into any issues with functionality, but the LOW voltage of the SPI Flash module was being pulled up to ~1.3V, and although it was working correctly, it was working out of spec. So we added the buffer to make sure the issue is fully resolved.
That make sense…shame on Ti…Thank you for the clarification. Any chance of getting a prototype to help shake out things?
acassis and I are working on porting Nuttx to the Spark.
sorry @david_s5; would love to help out but we don’t have any extra Cores at the moment; we have a few in our office but we need them for testing. looking forward to having a lot more handy
there is a mistake in the BOM, there is two C16 listed. The (10uF) should be labelled as C15 per layout and schematic.
not a big deal but I know manufacturing and a small typo can cause delays and extra costs. I also noticed the ICs are labelled as Us in the BOM. We should probably keep them the same
Thanks @Dup, we’ll take a look and fix asap.
It looks like it is labelled C15 at the moment. Could you confirm you were looking at version [core-bom-v1-130906.xlsx] ?
: https://github.com/spark/core/blob/master/Bill%20of%20Materials/core-bom-v1-130906.xlsx[quote=“Dup, post:13, topic:351”]
I also noticed the ICs are labelled as Us in the BOM. We should probably keep them the same
Good catch. Eagle’s defaults are U$ for semis, IC would be nice to have. I’ll include this change in the next revision.
It appears the error had been corrected in the version you supplied. I was using v0.23