[Solved] Problem with saving/reading from flash memory causing inability to connect/reflash

So I’m having some difficulties saving/reading from the flash memory, as mentioned above.
I found recently, after reflashing my core, I was unable to send/receive data from the core in any fashion until I do a factory reset.

The code in my firmware that seems to cause the problem consists of reading/writing to flash.
If I comment out the related code shown below, the problem doesn’t occur, and I am able to use other functions normally, sending/receiving/reflashing/etc.

The problem isn’t consistent either.
Without executing the save_color_to_mem function, I can occasionally get the core to execute other commands before it freezes up, and doesn’t seem to recognize any other cloud input.

If I execute the save_color_to_mem function, it stops accepting commands typically, and if I reset it, it doesn’t read from memory. I originally tried just reading/writing the 3 bytes that I needed, since based on information from here, I found that I could write odd bytes, and it shouldn’t be a problem (using the code found in the link seemed to work without issue).

Any suggestions? If you need any additional information, let me know.

#define DESIRED_LED_FLASH_ADDRESS 0x80000
...
int global_r, global_g, global_b;
...
void setup() {
...
	uint8_t temp_rgb[4];
	sFLASH_ReadBuffer(temp_rgb, DESIRED_LED_FLASH_ADDRESS, 4);
    global_r = temp_rgb[0];
    global_g = temp_rgb[1];
    global_b = temp_rgb[2];
...
}
...

int save_color_to_mem(){
    sFLASH_EraseSector(DESIRED_LED_FLASH_ADDRESS);
    uint8_t values_led[4] = { (uint8_t)global_r, (uint8_t)global_g, 
                              (uint8_t)global_b, 0 };
    sFLASH_WriteBuffer(values_led, DESIRED_LED_FLASH_ADDRESS, 4);
    return 1;
}

Hi @DanielBernard

Other user have had similar problems and I think you should consider the sFLASH_ functions as experimental at this stage. That said, I would try writing an even number of bytes. Other users were able load data via dfu-util and read it correctly from the core.

1 Like

Oh, agreed - I expect it to be somewhat messy for now.
Just to note, the above code that I’m using now does write an even number of bytes, I didn’t do a good job of explicitly stating that before, sorry.

Would I be correct in presuming that dfu-util is for pc->core connections only?
My particular application will be a closed environment, and all communication needs to be wireless.

I’ll keep testing, and see if I can get it working without issue.

Hi @DanielBernard

Yes, you are right: dfu-util is a PC/mac to core downloading (up uploading) program that works over USB to write both the internal flash on the processor and the external flash that you are using. If you build your firmware locally, that is one way to get it on the core.

I think the problem must be related to the fact the TI Wifi CC3000 and the external flash memory share an SPI bus (not the user SPI bus, a different one) and there are timing conflicts. That memory is written correctly when you do an over-the-air firmware update, so it does work in certain cases.

And I am sorry too that I didn’t notice the 4’s in your code earlier.

1 Like

Holy expletive, Batman, that extra information helped a ton!
Thank you so much @bko!

Knowing that the WiFi module and the Flash are on the same SPI bus made me think to add some delay before and after the commands that read/write.
After some testing, about 20ms of delay seems optimal as far as not interfering during the setup loop. 15ms was too short, as I had occasional blips where it error looped like before.

I’ve been trying to get this working for weeks, and it had been really intermittent before. Thanks again!

2 Likes

DanielBernard, you may also want to check out this topic for more information and what other members have tried :slight_smile:

I just wrote a test program with delay(20) around all the calls to sFLASH and it worked OK for me too. I am writing 256 bytes with incrementing values and then reading them back and checking them.

I think you are benefitting from the recent changes where calling delay() will let the WLAN code run. I think it could still fail on busy networks or if you were also using a TCP or UDP connection. I was thinking that using the new WiFi.off() and WiFi.on() could also be a good way to do this but it is a very big hammer.

OK, re-flashing your core while running this test is dangerous–it hung while starting the do the magenta thing. But it failed over to good firmware and I was able to flash a new program in without doing a factory reset.

I’ll definitely read into that some more. I’d looked through it a little while back, but it’s probably hinging on more than a month since I’ve looked at that topic. I’ll do so again.
Thanks for the reminder!

Agreed, I’ve had plenty of problems where it gets stuck in the setup loop, and I’m completely unable to flash until I factory reset.

That’s impressive, and kind of cool - I’ll admit, I can’t say I’ve experienced that.