Page 4 of 4
Re: Unstable partition API flashing functions
Posted: Tue Mar 28, 2017 2:29 am
by ESP_Angus
It's a menuconfig option, but it was only added very recently. If you have an IDF branch with the fixes discussed in this thread then you should have it, though.
Re: Unstable partition API flashing functions
Posted: Tue Mar 28, 2017 7:41 pm
by imtiaz
Hi Angus,
the "FreeRTOS Timer Task Priority" setting is not on the ""spi_flash_lock_period branch"" - so I'll have to wait for this branch to be merged into master first to test it.
Also - it seems that having a 5msec or so delay inside the socket server thread stops the lock up issue or at least minimises it.I can live with it for now.
Re: Unstable partition API flashing functions
Posted: Tue Mar 28, 2017 11:26 pm
by ESP_Angus
imtiaz wrote:
the "FreeRTOS Timer Task Priority" setting is not on the ""spi_flash_lock_period branch"" - so I'll have to wait for this branch to be merged into master first to test it.
If you get the latest master then you will have this fix. Very interested to find out if it makes a difference.
Angus
Re: Unstable partition API flashing functions
Posted: Thu Apr 27, 2017 9:52 pm
by imtiaz
Hi @ESP_Angus,
I''ve updated to the latest Master branch of the IDF (as of yesterday v2.0-rc1-666-g0fe765a9) . The function to calculate the Md5 hash using memory map of the SPI flash is now hanging and causing WDT reset.
Any ideas - Free rtos timer priority is 6 , my thread from which the function that maps the memory is called is set to 1
- '
1460 : 489252
1192 : 490712
File Size : 491904
Guru Meditation Error: Core 0 panic'ed (Interrupt wdt timeout on CPU0)
ets Jun 8 2016 00:22:57
rst:0x8 (TG1WDT_SYS_RESET),boot:0x16 (SPI_FAST_FLASH_BOOT)
ets Jun 8 2016 00:22:57
rst:0x7 (TG0WDT_SYS_RESET),boot:0x16 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0008,len:8
load:0x3fff0010,len:4288
load:0x40078000,len:10236
load:0x40080000,len:252
0x40080000: _iram_start at ??:?
entry 0x40080034
0x40080034: _iram_start at ??:?
W (89) boot: PRO CPU has been reset by WDT.
W (90) boot: WDT reset info: PRO CPU PC=0x400913d6
0x400913d6: rtc_clk_slow_freq_get at C:/esp32/esp-idf/components/soc/esp32/rtc_clk.c:432
(inlined by) rtc_clk_slow_freq_get_hz at C:/esp32/esp-idf/components/soc/esp32/rtc_clk.c:204
W (90) boot: WDT reset info: APP CPU PC=0xd75145c6
Re: Unstable partition API flashing functions
Posted: Fri Apr 28, 2017 1:51 am
by ESP_Angus
imtiaz wrote:
I''ve updated to the latest Master branch of the IDF (as of yesterday v2.0-rc1-666-g0fe765a9) . The function to calculate the Md5 hash using memory map of the SPI flash is now hanging and causing WDT reset.
Can you post the snippet of code that displays this problem? If you comment this calculation out does everything run as expected?
Re: Unstable partition API flashing functions
Posted: Fri Apr 28, 2017 2:11 am
by imtiaz
Yes - everything works if you dont call function below
Code: Select all
static BOOL VerifyBinFileFromFlash(const esp_partition_t* p , size_t FileLen , unsigned char * FileHash)
{
struct MD5Context MyMD5;
unsigned char MyDigest[16];
MD5Init(&MyMD5);
spi_flash_mmap_handle_t handle;
const void *image_data;
esp_partition_mmap(p, 0, FileLen, SPI_FLASH_MMAP_DATA, &image_data, &handle);
assert(image_data != NULL);
MD5Update(&MyMD5 , image_data, FileLen);
spi_flash_munmap(handle);
MD5Final(MyDigest , &MyMD5);
for(uint8_t i=0;i<16;i++)
{
TRACE_D("MD5 %d = Calc : %x , Rec : %x \n",i,MyDigest[i],FileHash[i]);
}
if(memcmp(MyDigest , FileHash , 16) == 0)
{
TRACE_D("File Hash Match \n");
return True;
}
else
{
TRACE_E("File Hash MisMatch !!!!!!!!!!!! \n");
return False;
}
}
Re: Unstable partition API flashing functions
Posted: Sun Jul 23, 2017 9:07 pm
by imtiaz
@ESP_Angus,
The problem is resolved - the mapped partition cannot be exactly the same size as the call to the MD5 function , needs to be 4 byte bigger I am assuming..
- Hi,
I still have an issue with the MD5 function - it is often just hanging.
called as follows:
MD5Update(&MyMD5 , image_data, FileLen);
If you try a file length of 256k (262144) you may see the issue.
If I call MD5Update in 256 byte chunks rather than the full file - it gets stuck when called with address 249856 ...
Code: Select all
{
uint32_t Hashed = 0;
while(Hashed!=FileLen)
{
MD5Update(&MyMD5 , image_data+Hashed, 256);
Hashed+=256;
TRACE_D("%d\n",Hashed);
}
}
and then I would get a WDT reset - quick resolution would be highly appreciated
Thanks
Imtiaz
Re: Unstable partition API flashing functions
Posted: Mon Jul 24, 2017 12:22 am
by WiFive
imtiaz wrote:the mapped partition cannot be exactly the same size as the call to the MD5 function , needs to be 4 byte bigger I am assuming..
You mean rounded up to the nearest 4 byte boundary?
Re: Unstable partition API flashing functions
Posted: Mon Dec 25, 2017 8:36 am
by pratik.yadav.455
Hello @ESP_Angus @ESP_Sprite
Having problem of AP drop off.
I created HTTP server.
In my application my client send file to server, And server Store that file in to SPIFFS .
More detail is on following thread.
http://bbs.esp32.com/viewtopic.php?f=13&t=3891
Is there anything i missed?
Let me know if need any information from my side.