Listening at 433 Mhz... SPI Flash Init FAIL! (is chip present?) [SOLVED]

[pedro.albuquerque]

Hi Felix,

Since my last post on this issue, I have been working on the code aimed to this board.
Yes, it's true, it was "sleeping" for quite some time and since last 3 ou 4 week I have resumed the project.

This time I was experiencing execution freezing , but as I am also adding a touch display ILI9341, so I assumed it was my fault (bug).

I found execution is freezing every time I turn power ON (connect USB cable).
If I reset the board, than code will not fail.

This was particularly challenging to detect as for debugging I was using Serial.print to understand were it was stoping.
When I start the debug console (both using Platformio on ATOM, or Arduino IDE) the board is reset, so I could never see the problem while debug this way.

So I used a FTDI connected to pins 8 and 9, no power from the FTDI, and a battery to power the VIN and GND.

I ended up isolating the problem confirming what is happening is actually the code is not freezing, BUT, the SPIFlash is not working (no read and no Write) .

I reduced it to the very least/simpler code using  SPIFlash_ReadWrite example, and debug Serial.print message on SPIFlash library .

The SPI.initialize call is not able to collect the devideID

Code Select Expand

/// setup SPI, read device ID etc...
boolean SPIFlash::initialize()
{
    char c;
  #if defined (SPCR) && defined (SPSR)
    _SPCR = SPCR;
    _SPSR = SPSR;
  #endif
  pinMode(_slaveSelectPin, OUTPUT);
  Serial.println("[SPIF] SS pin set to OUTPUT!"); // DEBUG
    Serial.print("[SPIF] DevideID!");Serial.println(readDeviceId(),HEX); // DEBUG[/b][/b]
    //while(!Serial.available());
    //Serial.print(c=Serial.read());
#ifdef SPI_HAS_TRANSACTION
  _settings = SPISettings(4000000, MSBFIRST, SPI_MODE0);
#endif
    Serial.println("[SPIF] SPISetting OK!"); // DEBUG
    Serial.print("[SPIF] DevideID!");Serial.println(readDeviceId(),HEX); // DEBUG

  unselect();
  wakeup();

   Serial.print("[SPIF] DevideID!");Serial.println(readDeviceId(),HEX); // DEBUG
    

  if (_jedecID == 0 || readDeviceId() == _jedecID) {
    command(SPIFLASH_STATUSWRITE, true); // Write Status Register
    SPI.transfer(0);                     // Global Unprotect
    unselect();
    return true;
  }
  return false;
}

the debug console (arduinoIDE) is showing  (first with Power ON, and than with Reset pressed)

Start...[SPIF] SS pin set to OUTPUT!
[SPIF] DevideID!FFFF
[SPIF] SPISetting OK!
[SPIF] DevideID!FFFF
[SPIF] DevideID!FFFF
Init FAIL!
Start...[SPIF] SS pin set to OUTPUT!
[SPIF] DevideID!EF30
[SPIF] SPISetting OK!
[SPIF] DevideID!EF30
[SPIF] DevideID!EF30
Init OK!

Question: did you experience this before ?

My suspicion is that the Flash Memory is defective.

Not sure how to debug it further... Any idea ?

(I have even redone all sodering to make sure there is no bad contact still, but If that was the case I would not expect this behaviour) .

[perky]

If the EEPROM itself is in sleep mode it won't respond correctly when probed. I think this has been covered before, try searching the forum for more.

Mark.

[Felix]

I think this thread and solution might be of interest:

https://lowpowerlab.com/forum/moteino/one-solution-to-moteino-failure-to-return-from-sleep/

[pedro.albuquerque]

Thank you Felix and perky,

In fact I still miss to understand what is going on.
i see in common with the thread you pointed me to that the code is sticked in the loop

Code Select Expand

  if (cmd != SPIFLASH_WAKE) while(busy());

of the command member of the SPIFlash library.
But the resemblance stops there as I am not putting my board to sleep in any moment.
I feel the problem as I power up the board, every time a power-up he board.

I even started to complicate by developing a state analyser from an ESP32 (but lets live that story aside for now  )

So, "as I cannot beat them I joined them", meaning, if a reset is solving my problem, I implemented a "smart" soft reset in my main code

Code Select Expand

#include <avr/wdt.h>
#define Reset_AVR() wdt_enable(WDTO_1S); while(1) {} // Soft reset Arduino using watchdog
.....


void setup(){

	// initialize Serial port for debugging
	Serial.begin(SERIAL_BAUD); //Initialize the Serial port at the specified baud rate
	Serial.println F("GPS AND TELEMETRY MODULE");
	Serial.println(VERSION);
	Serial.println F("Initializing...");

	Serial.print("Flash DeviceID:"); Serial.print(flash.readDeviceId());
	if(flash.readDeviceId() != 0xEF30){
           Serial.print("Soft Reset");
           Reset_AVR();
         }
....

So this way, in case my Flash is not responding I just do a reset.
For now its working.

(but I am still not satisfied. I hate when I do not understand what is going on....)

thank for your inputs, I may try to investigate in the "Release power-up" direction as on post https://lowpowerlab.com/forum/moteino/one-solution-to-moteino-failure-to-return-from-sleep/msg21452/#msg21452

[perky]

The flash itself is asleep from power up, all commands are ignored except the wakeup command. Therefore you cannot read the device ID or get status from the flash.

Could you try adding the following line before trying to read the ID:

Code Select Expand

flash.wakeup();

Mark.

[pedro.albuquerque]

Hi Pearky,

thanks for such a quick reply.
Just tried you suggestion

Code Select Expand

void setup(){

	// initialize Serial port for debugging
	Serial.begin(SERIAL_BAUD); //Initialize the Serial port at the specified baud rate
	Serial.println F("GPS AND TELEMETRY MODULE");
	Serial.println(VERSION);
	Serial.println F("Initializing...");
	Serial.println F("flash.wakeup");
	flash.wakeup();
	Serial.print("Flash DeviceID:"); Serial.println(flash.readDeviceId(),HEX);
	//if(flash.readDeviceId() != 0xEF30){
        //  Serial.print("Soft Reset");
        //  Reset_AVR();
        //}

as you can see just added it just before retrieving the deviceID, and commented out the Soft Reset, and the result was still that is stop in the While(busy()) loop

GPS AND TELEMETRY MODULE
GS LR MEGA V1.3.0
Initializing...
flash.wakeup

Flash DeviceID:FFFF
[FlashLOG] initialize

My previous line of investigation was to try to understand what AVR Soft reset actually does.
I analysed the behaviour of the main SPI pins, namely the MISO, MOSI, CS and CLK and I could not notice a diference in behaviour from a Power and a Hardware Reset.

I also tried to use a 10k Resistor to pullup the CS pin to Vcc to comply with manufacturer advice
"The /CS input must track the VCC supply level at power-up (see "Power-up Timing and Write inhibit threshold" and Figure 26). If needed, a pull-up resister on /CS can be used to accomplish this."


no sucess!