@kennethlimcp honestly I think there's just something wrong with his code which we need to see to continue debugging...
Does that mean i will have to call digole.begin() every time i want to write to the display, and SD.begin() each time i use the sd, and FRAM.begin() each time i read from FRAM?? see what im saying? i have 4 or 5 devices all using SPIā¦ at the same time on the same project, each one will change the CS line as begin is calledā¦ which is not really what i want. i need to initialize the SPI MOSI and MISO and CLK for all of themā¦ they are always the same but set my own CS for each.
Or am i getting confused and we are creating instances of the SPI class and each library has its own instance to use with its own CS line?? i dont knowā¦ its way over my headā¦ and Iām tiredā¦
@Hootie81, something needs to be clarified. The SPI firmware code, much like in the Arduino, does NOT control the chipselect line beyond the SPI.begin(cs) part. If you look at all your SPI device libraries, you will see that each controls its own CS line. The only thing is that when you call SPI.begin(cs) with a pin specified, it will set that pin to OUTPUT and write a HIGH to it (deselect). Not specifying a pin causes SPI.begin() to setup the A2/SS line which may not be desirable. 
1 Like
Ahhh i see i seeā¦ i thought that it did the CS automatically for you when you set it with begin(), so you didnāt have to control it manually like all the libraries did.
But what your saying makes total sense! it just sets up the pin and then you control itā¦
Next question: Multiple devices that use different modes and speedsā¦ whats the best practice for this? currently i call a function that sets up the mode and clock divider etc then calls SPI.begin() again.
@Hootie81, therein lies the rub. @BDub did some work on SPI and contributed some great pull requests to the firmware and here is what his conclusions were:
- Changing SPI speed or bit order does NOT affect the SPI bus
- Changing the SPI mode DOES affect the SPI bus and creates a āburpā when changed.
So it seems that you canāt change the SPI mode at will without affecting the SPI bus and devices. However, I am not quite sure what the effect is if all devices are deselected when the switch occurs. Perhaps @BDub can chime in here? 
As long as all of your SPI devices have a CS/SS enable, you can force them all to ignore the mode change side effects by setting the CS/SS to the inactive state (typically HIGH). At the time I was working with something that didnāt have this SS featureā¦ I think it was a 74LS595 LCD backpack or motor shield or something like that.
You can change the SPEED, BIT ORDER and MODE all without having to call BEGIN againā¦ just note that MODE changes should be done with CS/SS lines inactive (HIGH typically).
If all of your code is Round Robin style, one access after the otherā¦ youāll be fine just controlling everything simply with CS lines. But if you start to have multiple things accessing the SPI bus asychronously, youāll have to create a bus arbiter much like was done recently on the Spark Core between the CC3000 and on-board SFLASH.
1 Like
@BDub, any idea why changing SPI mode with the Digole and SD at before each read/write (before the CS enable) does not seem to work?
i think i tracked this downā¦ but i cant remember what it was
it may be āburpā related because the CS on SD cards works slightly differently??.. i cant remember! i gave up and called begin every time!
3 things are called by begin, i remember playing with theseā¦ but didnāt get very far
card.init(SPI_FULL_SPEED, csPin) &&
Ā Ā Ā Ā Ā Ā Ā Ā volume.init(card) &&
Ā Ā Ā Ā Ā Ā Ā Ā root.openRoot(volume);
it made things a real PITA as i had to keep closing the file, display text and then reopen the file
Do tell me more 
Initializing with the desired mode and each device separately works, but not switching back and forth between them at run time? Should we spinoff a new thread or offline discussion?
there was lots of chat about it in the digole display thread from about post 443
Read all that, still donāt see why calling SPI.begin() after MODE / SPEED changes is necessary to make the SD & Digole work. calling mode and speed already re-inits SPI, thereās only a few properties that are not re-initialized that donāt look like they would matter. The testing i did with on-the-fly mode, speed, bit order changes all workedā¦ i.e., SPI.transfer(val) was sending a proper value. I didnāt have anything to read from at the time, so perhaps thatās the part thatās an issue? If you are clocking out data still, and data is on the bus when you perform a SPI read but you donāt get that value in your code, then thereās definitely a port pin or peripheral setup issue.
Itās a strange oneā¦ digole is output only and SD is bi - directionalā¦ The issue was after displaying on the digole the SD would throw an error on cmd17 off the top of my headā¦
I did a bit of research a while ago and I think I put it down to the way CS works on an SD
@Hootie81, @BDub it looks like we will have to do a āformalā analysis of the issue since the SPI bus is so important. The odd device is the Digole which operates on mode 1 meaning data is clocked on the trailing (falling) edge of the SCK clock instead of the leading (rising) edge of Mode 0.
Since neither the SD or Digole libraries use interrupts to service the devices, it is safe to assume the code is running round-robin and synchronously. All this to say that SD transactions are mutually exclusive of Digole transactions. So in theory, with both devices deselected, the SPI hardware could be reconfigured without affecting the devices. As you pointed out @BDub, changing any SPI parameter re-writes the config structure out to the hardware essentially resetting it in the process. So why does calling SD.begin() before every SD transaction fix the issue but not changing the SPI mode before the low level driver where SPI.transfer() is called not work? Any thoughts?
1 Like
Nope. As you said its time to kick the butt of said SPI library and application code to figure this out. Break out the scope, data sheets, logic analyzer, pull your pants up and put your boots on.
3 Likes
I got a scope/logic analyzer the other dayā¦ should be here when i get backā¦ woot! this is what i am getting http://www.linkinstruments.com/mso19.html
I put it down to an SD problem not an SPI problemā¦
here is someone else with a similar problem with a totally different system to ours and his solution
could someone try sending 2 or so 0xFF out on the SPI after changing back to the right mode/speed without any CS going asserted and then try reading data from the SD?? i read somewhere this may clear some registerā¦ i would try myself but the core is packed awayā¦ the wife wouldnāt let me bring it on holiday!
and maybe a check to see if the SD library is setting the CS high after its finished?? maybe if a file is open or due to a bug it leaves the CS low??
here is a useful link that explains the error codes that we getā¦ under the initialization section there is a link to a flow chart.
http://elm-chan.org/docs/mmc/mmc_e.html
1 Like
Parts have arrived in Singapore and the PCB finishing looks beautiful!
PCB assembly is planned for next weekend and testing will happen immediately after. If we are able to ship next weekend, that would be awesome. 
5 Likes
Thought you guys might love to hear this.
1.) Tested 1 x hand-soldered board to make sure all the PCB is routed properly. 
2.) All the functionality of the board are tested working!
- Read/Write to Both FRAM
- List files in microSD card
- Card Detect
3.) Populated all the 30 boards for Manufacturing Run 1 WOOOHOOOO!
Unfortunately, i have not gotten to the Testing Jig yet. It will be designed this weekend together with the FRAM library.
More to come! 
4 Likes
Hereās a preview of the Testing Jig! Powered by a Spark Core. 
Hereās a Shield that passed all the tests (except uSD not tested yet)
UPDATE:
All the shields have been tested and ready for shipping
5 Likes
@kennethlimcp huge props, man! Those look awesomeāmy favorite part is obviously your DIY test jig
1 Like
@will, itās my 1st time designing a Testing Jig and Iām sure my future designs will turn out better! 
I have another feature Jig planned for an event in October so keep a look-out. 
1 Like