Why am I unable to program OTA a R4 Moteino?

[luisr320]

Hi!
I have been pulling some hair for the last couple of days with this and I give up.
I'm trying to Wirelessly Program (WP) a R4 Moteino but for some reason it doesn't work.

If I WP a simple Blink sketch everything works fine. But when I try to upload the following sketch, it is transferred with success but it isn't loaded into the Moteino EPROM after the reset. The previous sketch is still there. This sketch has 23.426 byte, or 72% of the available memory after compilation. Is this because it is too large?

I'm posting the file as an attachment.

Can someone please look at it and tell me what am I doing wrong?

[Felix]

Hi Luis,
I looked at your sketch and I think it looks good. The assumption is that CheckForWirelessHEX(radio, flash, true); is called often enough to pick up the wireless hex transfer. You mentioned this does happen and the image transfer takes place.
The Moteino has to have DualOptiboot and the FLASH MEM, I assume this is true.
Does the Moteino RESET after the transfer?
Can you load the SPIFLash_read-write sample sketch into that moteino and look at what is in the FLASH MEM with the 'd' command?
This is to confirm that the image is actually transferred into the FLASH chip. This command will read the first 256 bytes, in HEX format.

[luisr320]

Hello Felix. Thank you for your reply.
I do confirm that the transfer is performed successfully, with a message of success at the end of the transfer. I tried both Wireless Transfer GUI apps and both work well with this Moteino if I upload a simple Blink sketch. At the end of the transfer, the Moteino resets correctly, but the old sketch remains the one that is run. And I do have the Flash chip "factory assembled".
regarding the sketch that you refer, do I load it by itself or do I mix it within my sketch?

[Felix]

Basically after a valid successful transfer the image sits in the FLASH and the atmega is reset. The bootloader takes over and checks if a new image is waiting in the FLASH, if so it replaces the old sketch and then erases the first 32K block of the FLASH (atmega328).
If the transfer is successful but the bootloader job fails, I am curious to see what is the content of the FLASH.
So after your partially successful transfer you can just take that node and load it with the SPIFLASH_readwrite sketch to examine the content of that Moteino's FLASH memory. So you just overwrite whatever old sketch to be able to look at the memory. Please report back with what the serial monitor dumps when you press 'd'.

[luisr320]

Ok, i'll do that ASAP.
Thank you

[TomWS]

Basically after a valid successful transfer the image sits in the FLASH and the atmega is reset. The bootloader takes over and checks if a new image is waiting in the FLASH, if so it replaces the old sketch and then erases the first 32K block of the FLASH (atmega328).
If the transfer is successful but the bootloader job fails, I am curious to see what is the content of the FLASH.
So after your partially successful transfer you can just take that node and load it with the SPIFLASH_readwrite sketch to examine the content of that Moteino's FLASH memory. So you just overwrite whatever old sketch to be able to look at the memory. Please report back with what the serial monitor dumps when you press 'd'.

Felix,
it would be useful if there was a mod to the Wireless Programming Node example which stopped after download, didn't reset, and provided Flash Read/Dump capability.  Then you could examine the flash loader blocks to see if they are corrupted.

Tom

[luisr320]

Some more hair pulling and finally some conclusions but no solutions.

I figured that since all went well with a different sketch, like a simple blink, the problem should be on the sketch itself.

So after a LOT of trial and error I narrowed it down to line 271 of this new sketch that I'm uploading as an attachment to this message, ver. 12.

When I fill the Nokia 5110 buffer with a message larger than 3 characters on this line and upload the sketch trough the FTDI, if I try to send the same sketch again wirelessly, it doesn't upload at all.

But if the messege is up to 3 characters, it will upload and update the EEPROM as expected.

So for some weird reason, when the loop() goes trough these lines:

(...)
else
  {
    newtimer = millis(); //start counting the time since LOS
    if (newtimer > (oldtimer + 5000))
    {
      resetdisplay();
      display.print("..."); //<--------------LINE 271
      display.display();
      newbuzztimer = millis();
      if (newbuzztimer > (oldbuzztimer + 2000))
      {
        oldbuzztimer = newbuzztimer;
        Blink(BUZZ,5);
      }
    }
(...)

it works fine and I can wirelesslly upload a new sketch just fine.

But trough this:

  else
  {
    newtimer = millis(); //start counting the time since LOS
    if (newtimer > (oldtimer + 5000))
    {
      resetdisplay();
      display.print("Data link lost..."); //<--------------LINE 271
      display.display();
      newbuzztimer = millis();
      if (newbuzztimer > (oldbuzztimer + 2000))
      {
        oldbuzztimer = newbuzztimer;
        Blink(BUZZ,5);
      }
    }

the next wireless upload will not go trough.

I tried to insert a delay() after that line for 500 and even 1000, but the result was the same.

[luisr320]

And this happens even if I disconnect the LCD

[Felix]

Tom - I see what you're saying but FWIW this has never really been a problem except when a customized sketch itself somehow interferes with the WP. And in fact if the WP does manage to start then it should go all the way since the state machine is built in such a way that if the whole image is not 100% transferred it would stop, erase what was placed in the FLASH and abort. And also the data should have no way of being corruptly transferred, unless the FLASH chip is bad, which again i've never seen.

Luis, In your first post you said that the basic WP example with a blinky works, so I am not worried that there is any issue with the radio, the bootloader or the FLASH MEM. So it's something in your sketch that interferes, probably the LCD.

Based on what Luis is reporting I think it might have to do with the LCD CS/SPI interfering with the SPI of the radio/flash or something like that. Luis, you mentioned if you disconnect the LCD it still bugs out, what if you completely filter out the LCD code?
Otherwise, can you ensure that when the LCD is being interacted with, the interrupts are disabled and the LCD SPI CS line is always pulled up when it is not in use... that is crucial.

[TomWS]

Tom - I see what you're saying but FWIW this has never really been a problem except when a customized sketch itself somehow interferes with the WP. And in fact if the WP does manage to start then it should go all the way since the state machine is built in such a way that if the whole image is not 100% transferred it would stop, erase what was placed in the FLASH and abort. And also the data should have no way of being corruptly transferred, unless the FLASH chip is bad, which again i've never seen.

Felix, I agree that the value in the example node is limited, but it would provide a common snippet that others could include in their custom implementation.

Tom

[Felix]

Felix, I agree that the value in the example node is limited, but it would provide a common snippet that others could include in their custom implementation.
Tom

Yup so I think this could be a merger between the WP_Node and SPIFlash_readWrite examples, with a #define that enables that feature, commented out by default?

[luisr320]

Regarding my problem, though I have not really figured out what were the forces envolved that didn't allow me to wirelessly upload a sketch into my MOTEINO R4, I managed to rearrange the code so that instead of having the CheckforWirelessHex() being checked on every loop() run, it will only be checked when in the Firmware Update menu. This way the LCD Spi is quiet while there is a local loop after the text is displayed waiting for the Hex header or for the next menu button to be pushed, without any text refreshing.
"A good idea is one that works".
I'll post my new project soon.
Thank you for your interest.
Luis

[Felix]

Thanks for the update Luis,
What type of LCD are you using? And what LCD library?

[luisr320]

The LCD is a Nokia 5110 just loke this one:


And the library is from Adafruit:
https://learn.adafruit.com/nokia-5110-3310-monochrome-lcd/graphics-library

This LCD has a pin to control the backligh that is connected to the ground to turn it ON. How do I connect it to an analog pin to get some control on the backgroud brightness?

[Felix]

Ah, now I remember I looked at your sketch and I saw you used the adafruit lib for 5110, but then I forgot
I was using that lib also in initial testing but it's too slow and bulky and uses too much memory, and is very limited compared to u8glib...
You can control the brightness by using a PWM pin, then use AnalogWrite(PWMPIN, 0..255) to alter the brightness.