LowPowerLab Forum

Hardware support => General topics => Topic started by: WhiteHare on March 12, 2016, 08:35:04 PM

Title: How to get SPIFlash Library to work on a clone? [ANSWERED]
Post by: WhiteHare on March 12, 2016, 08:35:04 PM
I'm building a clone so as to more directly measure current used by individual components, and for other experimentation also (checking several permutations on the relative placement of components and comparing the  resulting effect on RSSI noise).  However, I've hit a wall on getting Felix's spiflash library to work with the winbond flash on the clone.  Using the diagnostic sketch from a different spiflash library ( https://github.com/Marzogh/SPIFlash), the windbond chip is confirmed as being the same on both the clone and the Moteino (diagnostic output is exactly the same):
Code: [Select]
------------­Initialising Flash memory..........


----------------------------------------------------------------------------------------------------------------------------------
                                                           Get ID                                                                 
----------------------------------------------------------------------------------------------------------------------------------
                                                       Winbond W25X40BV
----------------------------------------------------------------------------------------------------------------------------------
	JEDEC ID: ef3013h
	Manufacturer ID: efh
	Memory Type: 12h
	Capacity: 3013h
	Maximum pages: 2048
----------------------------------------------------------------------------------------------------------------------------------
                                                          Write Data                                                              
----------------------------------------------------------------------------------------------------------------------------------
	Data written without errors
----------------------------------------------------------------------------------------------------------------------------------
                                                          Data Check                                                              
----------------------------------------------------------------------------------------------------------------------------------
	Data Written	||		Data Read		||		Result
----------------------------------------------------------------------------------------------------------------------------------
	35		||		35			||		Pass
	-110		||		-110			||		Pass
	4520		||		4520			||		Pass
	-1250		||		-1250			||		Pass
	876532		||		876532			||		Pass
	-10959		||		-10959			||		Pass
	3.1415		||		3.1415			||		Pass
	123 Test !@#	||		123 Test !@#		||		Pass
	inputStruct	||		outputStruct		||		Pass
	0 - 255		||		0 - 255			||		Pass
----------------------------------------------------------------------------------------------------------------------------------
                                                     Check Other Functions                                                        
----------------------------------------------------------------------------------------------------------------------------------
			Function		||		Result
----------------------------------------------------------------------------------------------------------------------------------
			powerDown		||		Error code: 0x06
Pass
			powerUp			||		Pass
			sectorErase		||		Pass
			chipErase		||		Pass
----------------------------------------------------------------------------------------------------------------------------------

Also,  the other spiflash library has no problem interacting with the winbond chip, whether it be on the Moteino or on the clone.  On the other hand, Felix's library works on the Moteino, but hangs on the clone during flash initialization.   :o  In case you're wondering, the diagnostics show the same error code 0x06 on both the clone and the moteino (it means CANTENWRITE), and it also gives a "pass" on both.

Anyone have any idea what might be causing Felix's spiflash library to hang on the clone?  Aside from the winbond chip itself, the clone is just a 3.3v 8Mhz Pro Mini.  On both the Moteino and the clone, chip select for the flash memory is D8.
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: jra on March 13, 2016, 09:25:17 AM
Can you wire it up to a 328p on a breadboard and run it at 3v3@16MHz to make sure there are no unanticipated timing dependencies?
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: WhiteHare on March 13, 2016, 03:54:33 PM
Excellent idea!  So, I followed up on your suggestion and wired up a bareduino that uses a 16mhz crystal and hooked it up to the flash memory.  I tried running the example sketch titled "SPIFlash_ReadWrite" and...the exact same result.  :'(  I also confirmed that the alternative SPIFlash library (the one that can do diagnostics) can still read and write to the flash memory (the same as before) from the bareduino, so no change there either.  Anyhow, it was a worthwhile experiment, because now at least we know it's not purely a 16mhz vs 8mhz difference.  But what else could it be?

I've also tried swapping out the memory chip and using a different one.  No change.   :'(

I notice LowPowerLab's current spiflash library still uses some functions that have been deprecated.  Maybe that has something to do with it?
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: TomWS on March 13, 2016, 04:26:17 PM
Quote from: WhiteHare on March 13, 2016, 03:54:33 PM
Excellent idea!  So, I followed up on your suggestion and wired up a bareduino that uses a 16mhz crystal and hooked it up to the flash memory.  I tried running the example sketch titled "SPIFlash_ReadWrite" and...the exact same result.  :'(  I also confirmed that the alternative SPIFlash library (the one that can do diagnostics) can still read and write to the flash memory (the same as before) from the bareduino, so no change there either.  Anyhow, it was a worthwhile experiment, because now at least we know it's not purely a 16mhz vs 8mhz difference.  But what else could it be?

I've also tried swapping out the memory chip and using a different one.  No change.   :'(

I notice LowPowerLab's current spiflash library still uses some functions that have been deprecated.  Maybe that has something to do with it?
Dumb question: Did you configure D10 as an output?

Tom
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: WhiteHare on March 13, 2016, 05:03:31 PM
Actually, it was a smart question because no, I wasn't.  So, I guess it defaulted to slave mode rather than master mode, and that explains the hang (though I don't understand why the Moteino didn't also hang....).

So, fixed that, and now there's no more hanging.   :)  Thanks! 

I've moved forward to merely "Init FAIL!"   :(  Well, at least it's progress.   8)

[Edit: For some reason, the lowpowerlab SPIFlash library is reading jedecID as 0, which is what's causing the "Init FAIL!".  The other SPIFlash library reads it correctly, so it's not a hardware problem per se.]
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: WhiteHare on March 14, 2016, 07:08:24 PM
To debug the init fail, I'm now intercepting the SPI transfer calls.  On the exact same hardware (using Arduino IDE 1.6.5), the LowPowerLab's SPIFlash library fails fairly quickly during initialization on its example application:

Code: [Select]
Start...  
  Tx=0x5
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0xAB
  Rx=0x0
  Tx=0x9F
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
Init FAIL!

whereas the alternate SPIFlash library (I wish it had a different name) that can do diagnostics moves ahead without problem on its diagnostics application:

Code: [Select]
Initialising Flash memory..........
  Tx=0x5
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x90
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0xEF
  Tx=0x0
  Rx=0x12


----------------------------------------------------------------------------------------------------------------------------------
                                                           Get ID                                                                 
----------------------------------------------------------------------------------------------------------------------------------
  Tx=0x5
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x9F
  Rx=0x0
  Tx=0x0
  Rx=0xEF
  Tx=0x0
  Rx=0x30
  Tx=0x0
  Rx=0x13
  Tx=0x5
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x90
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0xEF
  Tx=0x0
  Rx=0x12
                                                       Winbond W25X40BV
----------------------------------------------------------------------------------------------------------------------------------
	JEDEC ID: ef3013h
	Manufacturer ID: efh
	Memory Type: 12h
	Capacity: 3013h
	Maximum pages: 2048
----------------------------------------------------------------------------------------------------------------------------------


The 0x05 transfer command is an SPIFLASH_STATUSREAD.  It both libraries, it returns just 0x00.

The 0xAB transfer made by LowPowerLab's library is a wakeup call to the flash memory, which the other library does not do.  However, merely commenting that out (to minimize the differences) doesn't fix the problem.

The 0x9F command (a request for the JEDEC ID) made by LowPowerLab's library is what forces the failure, as it only returns 0x0000, whereas when the alternate library later issues that same 0x9F command (later down the page), it elicits the correct response (0xEF3013), starting with the very next transfer.

Interestingly, the alternate library's earlier call of 0x90, which is to read the Manufacture/Device ID, actually takes a while and returns 0x000000EF12.  The timing of that latent response roughly coincides with the failure on the LowPowerLab code, which immediately aborts after receiving 0x0000.  Makes me wonder whether the lowpowlab library code would have eventually elicited the desired response if it had tried longer before giving up.

The above is what happens when running on an 8Mhz clock.  I'll now have a look at what happens at 16Mhz.

[Edit1:  So, I re-ran everything on a atmega328p using a 16Mhz crystal and a Duemilanova bootloader (offhand, I'm not sure what the fuse settings are), and the results were exactly the same.]

[Edit2: running the alternate spiflash libary and diagnostic software on a Moteino also produces exactly the same results as it does on either the 8mhz or 16mhz clones]

Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: WhiteHare on March 14, 2016, 09:08:16 PM
Obviously, the lowpowlab library does work on the Moteino, and for comparison, the results are:

Code: [Select]
Start...  
  Tx=0x5
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0xAB
  Rx=0x0
  Tx=0x9F
  Rx=0x0
  Tx=0x0
  Rx=0xEF
  Tx=0x0
  Rx=0x30
  Tx=0x5
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x6
  Rx=0x0
  Tx=0x5
  Rx=0x0
  Tx=0x0
  Rx=0x2
  Tx=0x1
  Rx=0x0
  Tx=0x0
  Rx=0x0
Init OK!


The decisive difference is that the 0x9F  command (a request for the JEDEC ID) immediately elicits a  correct response of 0xEF30 instead of 0x0000.

But why the difference?
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: WhiteHare on March 14, 2016, 09:43:09 PM
So, answering my own question that I posed earlier, as to whether or not if the lowpowerlab library had simply been more persistent, maybe it would have elicited a response: no, it wouldn't have.

To find out, I added a bunch more SPI.transfer(0) calls after the original 0x9F command, and it never does respond with anything other than 0x00.   :'(

Code: [Select]
Start...  
  Tx=0x5
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0xAB
  Rx=0x0
  Tx=0x9F
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
Init FAIL!

It's truly weird with a beard.   I guess I'll have to slap on a logic analyzer and/or an o-scope to sort this, or at least add some color as to what might be going wrong.  Since it appears not to be responding, I suspect there may be a frequency mismatch of some kind.  Except why would the alternate SPIFlash library (the one that can do diagnostics) work on all the platforms without any apparent problems? 
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: WhiteHare on March 15, 2016, 06:15:43 AM
I'm now noticing that the maximum input capacitance and output capacitance on this memory chip is 6 and 8 picoFarad respectively.  That seems pretty low.  I'm having trouble even properly measuring its I/O using the logic probe and o-scope that I have, and I'm beginning to wonder if that might be why.
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: WhiteHare on March 15, 2016, 12:43:57 PM
Even on the Moteino, getting good readings on MISO and MOSI is elusive (see attached).  SPI Clock and Chip Select are easily read though.  It does confirm that the SPI Clock is running at 4Mhz, as it should be, and Chip Select is working (obviously), but otherwise it's next to useless...



Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: WhiteHare on March 15, 2016, 04:46:22 PM
I added some dedicated male headers close to the flash memory chip for attaching logic probe leads, and now I can capture the full SPI session on the clone.  For the alternate SPIFlash library, it works without a hitch (see attachment).  Its SPI clock is running at 2Mhz.
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: WhiteHare on March 15, 2016, 04:57:48 PM
In contrast, the LowPowerLab SPIFlash library, running its stock example, appears to be stuck in a crazy loop.  It's running on the exact same hardware, with the exact same logic probes, as the diagnostic SPIFlash library above, all of which haven't been touched at all.  Only the library and sketch have changed.  It's running the SPI clock at 4Mhz.  Maybe slowing the SPI clock down to 2Mhz will (I hope) fix the problem (see attachment) that's presently manifesting when the LPL SPIFlash library is in use.

Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: WhiteHare on March 15, 2016, 06:06:13 PM
Well, unfortunately, slowing the SPI clock down to 2Mhz didn't solve it.  Nor did slowing it to 1Mhz, or 500Khz, or even 100Khz.  No change with any of them.

So, back to square 1. 

Does anyone have any suggestions?

[Edit1: It turns out that the very act of measuring the SPI lines using my logic probe will, if using the LPL SPIFlash library (but not the diagnostic SPIFlash library), cause the loop to happen.  If I disconnect the logic probe from my computer, then the loop doesn't happen (but init still FAILS).  So, once again, what could account for the difference between the LPL Library being logic probed and the other library?  I guess I need some other way (?) to probe it.]

[Edit2: Commenting out the wakeup command call from the initialize method in the LPL SPIFlash library has allowed me to run the logic probe without encountering the loop.  From reading the datasheet, I'm fairly sure it wasn't invoked correctly  right anyway.  Besides, the diagnostic Flash library works just fine without calling it.]
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: WhiteHare on March 15, 2016, 08:06:16 PM
Well, according to the logic probe, the root cause of the problem when the LPL SPIFlash library is running is that MOSI does not seem to transmit anything.  Thus, there is no response elicited over MISO.

i.e. it looks as though SPI itself isn't working properly.  Perhaps there is some conflict between the LPL SPIFlash library and the SPI library but which, for some reason, does not manifest on a Moteino?

So, now why that would be--and only with the LPL SPIFlash library and not the alternate diagnostic library--is the next question.  Does anyone here know anything about SPI that might help answer the question?

I'm obviously grasping at straws here, but could fuse settings have anything to do with it?  What other differences could there be?
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: Felix on March 16, 2016, 08:34:01 AM
Just a wild guess ... capacitive coupling maybe distorting the signal to the point where it's garbled? But ... at such low speeds (16mhz) I would not really expect this.
What does this clone look like?
Title: Re: How to get SPIFlash Library to work on a clone? [ANSWERED]
Post by: WhiteHare on March 16, 2016, 09:24:36 AM
Photo attached.
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: Felix on March 16, 2016, 09:47:59 AM
Is this a $2 arduino mini? :P
Any doubt that's a genuine atmega chip or is a reject?
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: WhiteHare on March 16, 2016, 10:19:14 AM
Quote from: Felix on March 16, 2016, 09:47:59 AM
Is this a $2 arduino mini? :P
yes

Quote from: Felix on March 16, 2016, 09:47:59 AM
Any doubt that's a genuine atmega chip or is a reject?
I don't know.  The hardware does work without a hitch though (see reply #10 above) using the diagnostic spiflash library.  I've also tried it with different (DIP) chip and hardware (a virtualbotix bareduino 16mhz atmega328p purchased through amazon), and it's the same results.  So, given the same results using two very different pieces of hardware...
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: emjay on March 16, 2016, 10:35:27 AM
@Whitehare,

If you want to dig deeper, I suggest you 'deadbug' wire the little flash daughter board direct to the pins on the clone and don't have the SPI bus signals connecting to the breadboard at all.  There is considerable capacitance loading on the signals with the current setup.

Adding scope and/or logic probe just makes the loading worse.  You can check the waveform rise/fall times if you put a tiny C value in series with the probe e.g. 1.5pf with a typical 15pf probe tip will divide the signal by ~10 (compensate with extra gain) but only be a small additional load on the bus signal.   You are looking for runts, slow risetimes, ringing etc.

If you don't have a small value SMD handy, just use a cm of tightly twisted pair, the self-capacity will do the trick.
 
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: emjay on March 16, 2016, 11:11:06 AM
@WhiteHare,

I doubt it - their input capacitance is too high.  At least while you are debugging, you need to get the bus loading capacitance down.
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: WhiteHare on March 16, 2016, 11:12:35 AM
Thanks!  That's what I didn't know.  I'll skip the optocouplers then.
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: WhiteHare on March 16, 2016, 04:35:26 PM
OK, I threw together a deadbug (see attached), and... same results.  Argh!  As before, the alternate SPIFlash library works, but the LPL SPIFlash library results in "Init FAIL!".  I even deleted the LPL SPIFlash library and downloaded a fresh new one from LPL github repository.  Same results.

In case you're wondering, the Winbond flash chips came from Digikey, so presumably no problem there.  For the deadbug I used a different Winbond flash chip, just in case the previous two might have been dodgy.  Obviously, that made no difference.

If it *is* a capacitance issue, then maybe the flash chip's breakout board is the source?  I'm not sure I have the skill to deadbug without it, but I suppose I could try.  But if that's the case, why on three different hardware testbeds now does the diagnostic SPIFlash library work and the LPL SPIFlash library fail?  I don't get it: if it were a hardware problem wouldn't the diagnostic SPIFlash library fail too?



Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: emjay on March 16, 2016, 08:23:15 PM
Neat. Now what do the bus signals look like on the scope (LPL v. non-LPL library)?

Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: Felix on March 17, 2016, 09:51:16 AM
You showed a logic trace earlier where issuing 0x9F (read ID) from the other library, gets the right ID back, but issuing the same command with my library fails.
That's good, but confusing to me, why the same code would work on a Moteino... but not on a 'clone'. So definitely some issue somewhere, i'm on the fence between an electrical issue or firmware/library. I was going to suggest fuses, but that can't be it. SPI Initialization maybe? Clocks really don't matter that much, 4mhz is not a problem, never saw an issue, BUT with a clone where capacitive coupling might be an issue you could divide by 8 or 16 instead of just 4.

EDIT: Can you try my SPIFlash library at this point in history (https://github.com/LowPowerLab/SPIFlash/tree/46b3d40a0c07b2076ac303a76fa29e9742ccbb9c), when it did not include the SPI_TRANSACTION support?
How about trying the latest version with IDE 1.0.6 where SPI_TRANSACTION was not available?
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: TomWS on March 17, 2016, 10:22:46 AM
Quote from: Felix on March 17, 2016, 09:51:16 AM
You showed a logic trace earlier where issuing 0x9F (read ID) from the other library, gets the right ID back, but issuing the same command with my library fails.
Actually, if you look at the posted sequence, the SPIFlash Library issues a 9F command (Read JEDEC ID) while the other sequence was issuing a 90 command (Read Manufacturer ID).

Quote
EDIT: Can you try my SPIFlash library at this point in history (https://github.com/LowPowerLab/SPIFlash/tree/46b3d40a0c07b2076ac303a76fa29e9742ccbb9c), when it did not include the SPI_TRANSACTION support?
How about trying the latest version with IDE 1.0.6 where SPI_TRANSACTION was not available?
Another thing to check, using the current library, is that SPI_HAS_TRANSACTION is defined.  Maybe this was lost (or whimsically changed) in this version of the IDE.

Tom
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: Felix on March 17, 2016, 01:53:31 PM
Quote from: TomWS on March 17, 2016, 10:22:46 AM
Quote from: Felix on March 17, 2016, 09:51:16 AM
You showed a logic trace earlier where issuing 0x9F (read ID) from the other library, gets the right ID back, but issuing the same command with my library fails.
Actually, if you look at the posted sequence, the SPIFlash Library issues a 9F command (Read JEDEC ID) while the other sequence was issuing a 90 command (Read Manufacturer ID).

Tom, I was referring to this post (https://lowpowerlab.com/forum/index.php/topic,1714.msg12374.html#msg12374) where @WhiteHare mentions that with the alternate library, reading the id works. The trace shows a 9F command followed by the expected 0xEF30 reply. At least that's what I see.
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: WhiteHare on March 18, 2016, 01:11:11 AM
Quote from: Felix on March 17, 2016, 09:51:16 AM
EDIT: Can you try my SPIFlash library at this point in history (https://github.com/LowPowerLab/SPIFlash/tree/46b3d40a0c07b2076ac303a76fa29e9742ccbb9c), when it did not include the SPI_TRANSACTION support?
No improvement when running it on 1.6.5. 


Quote from: Felix on March 17, 2016, 09:51:16 AM
EDIT:
How about trying the latest version with IDE 1.0.6 where SPI_TRANSACTION was not available?

Success!  Running the library above that you linked to on IDE 1.0.6 produces "Start...Init OK!"   :)  I didn't even have to add
Code: [Select]
pinMode(10,OUTPUT);
to the example sketch that came with the library.  I also didn't have to comment out the wakeup() function call in the flash initialize method.  In both cases, just running the code as given does not appear to result in any hangs or fails.

[UPDATE: the current SPIFlash library also appears to work under Arduino IDE 1.0.6.  i.e. 1.0.6 is the key!

I wonder why it doesn't it work on the later IDE releases, like 1.6.5?]
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: WhiteHare on March 18, 2016, 01:27:56 AM
Quote from: TomWS on March 17, 2016, 10:22:46 AM
Another thing to check, using the current library, is that SPI_HAS_TRANSACTION is defined. 
I have  confirmed that, yes, it is defined.
Title: Re: How to get SPIFlash Library to work on a clone? [ANSWERED]
Post by: emjay on March 18, 2016, 03:24:58 AM
@WhiteHare,

Well done - persistence pays off.  Now digging out the actual reason will probably need a look at the generated code in combination with monitoring the SPI traffic. Presumably you can just focus on the offending transaction(s) in a loop - if you're not tempted to score the victory and just move on... 
Title: Re: Is there some trick to getting spiflash to work on the winbond flash in a clone?
Post by: Felix on March 18, 2016, 08:23:47 AM
Quote from: WhiteHare on March 18, 2016, 01:11:11 AM
Success!  Running the library above that you linked to on IDE 1.0.6 produces "Start...Init OK!"   :)  I didn't even have to add
Code: [Select]
pinMode(10,OUTPUT);
to the example sketch that came with the library.  I also didn't have to comment out the wakeup() function call in the flash initialize method.  In both cases, just running the code as given does not appear to result in any hangs or fails.

[UPDATE: the current SPIFlash library also appears to work under Arduino IDE 1.0.6.  i.e. 1.0.6 is the key!

I wonder why it doesn't it work on the later IDE releases, like 1.6.5?]
Great work.
It's pretty amazing, how does it feel to discover firmware (the latest greatest IDE 1.6.5) is the problem and that just wasted a few days of your life, and an unknown number of hairs and neurons? Relief and grief huh?

I never liked any of the IDEs above 1.0.6. That one doesn't have the fancy library management, but it just works. I'm not 100% sure what to say about SPI_TRANSACTIONS, they seem to be a good thing, seem to work and are meant to keep newbies from having to know what's going on under the SPI hood. You confirmed the latest SPIFlash (includes SPI_TRANSACTION support) also works in 1.0.6, which of course is what I use and I can also confirm that.

Anyway, maybe something can be done in the SPIFlash lib to make it work in 1.6.5, maybe some little patch or something. If you find the magic bullet let me know :)
Title: Re: How to get SPIFlash Library to work on a clone? [ANSWERED]
Post by: WhiteHare on March 19, 2016, 09:16:29 AM
Quote from: emjay on March 18, 2016, 03:24:58 AM
Now digging out the actual reason will probably need a look at the generated code in combination with monitoring the SPI traffic.

I concur.  The error seems like it's compiler related.

We know from a different thread that the Arduino.cc folks monkeyed with the GCC compiler optimization settings in some of the recent IDE releases, resulting in previously functional sleep code becoming dysfunctional.  There the solution was to turn-off compiler optimizations using compiler directives embedded with the relevant code. 

I have run into a GCC compiler problem on one prior occasion that was unrelated to all of this (a local variable wasn't getting initialized to the value that the c-code clearly meant it to be).

Is there a better compiler that anyone here is using?  I was disappointed to find out that even Visual Studio (as well as a number of other Arduino IDE "alternatives") uses GCC.
Title: Re: How to get SPIFlash Library to work on a clone? [ANSWERED]
Post by: WhiteHare on March 20, 2016, 02:30:13 PM
Good news!  If I build using the Arduino IDE 1.0.6, then I no longer need to use a DTR-to-GND connection on my Moteino R4 when it's utilizing flash memory and when powered by battery-only (no FTDI).   ;D

So, although this started out as a thread on clone use of flash memory, the information gained is turning out to be highly beneficial in my use of Moteino R4's.  8)  By the way, the R4 continues to be my preferred wireless platform.   :)

[Edit: I do, however, still need the megaohm pulldown resistor on D12 if I am to wake-up the flash memory after explicitly putting the flash memory to sleep.  Without the pulldown, even if the R4 firmware is built using IDE 1.0.6, the result is still in a hang when trying to wake the flash memory.   :(  The unit I tested is an R4 running direct from two AA batteries and with the stock LDO voltage regulator removed.]
Title: Re: How to get SPIFlash Library to work on a clone? [ANSWERED]
Post by: WhiteHare on April 07, 2016, 02:47:38 PM
Arduino 1.0.6 shipped with avr-gcc version 4.3.2 and AVR-Libc 1.6.4, and Arduino 1.6.0 ships with avr-gcc version 4.8.1 and AVR-Libc 1.8.0.  So, maybe that has something to do with it.  I'd much prefer to run the current Arduino IDE than an old one.
Title: Re: How to get SPIFlash Library to work on a clone? [ANSWERED]
Post by: dzubey on March 03, 2017, 06:40:43 PM
Wanted to 'me too' this issue.

I have about 30 motinos that started out working great, then after a few software revisions in the last 3 years, I can no longer power them with a non-ftdi connector, where they are not reset on boot. Indeed backing down to 1.0.6 showed more promise. I can't go live with that version however. It's a deal breaker.

They *do* start up on battery power regularly when i touch them with my finger, so that suggests a capacitance issue.

I tried various bypass capacitance values connected between DTR and ground, and no go at all. Pulling it down to ground also doesn't work reliably. I'm going to try a 1M to ground, see what that does, but really need these motinos to work out-of-the box with the newest (or reasonably new) software. I would like to scale this project up by a factor of 3 or 4 soon here.

Can anyone give any further information on what they've found since last update?