{"action":"created","issue":{"url":"https://api.github.com/repos/espressif/esp-idf/issues/1650","repository_url":"https://api.github.com/repos/espressif/esp-idf","labels_url":"https://api.github.com/repos/espressif/esp-idf/issues/1650/labels{/name}","comments_url":"https://api.github.com/repos/espressif/esp-idf/issues/1650/comments","events_url":"https://api.github.com/repos/espressif/esp-idf/issues/1650/events","html_url":"https://github.com/espressif/esp-idf/issues/1650","id":299479782,"number":1650,"title":"[TW#18663] Coredump inconsistency..","user":{"login":"ammaree","id":3227544,"avatar_url":"https://avatars1.githubusercontent.com/u/3227544?v=4","gravatar_id":"","url":"https://api.github.com/users/ammaree","html_url":"https://github.com/ammaree","followers_url":"https://api.github.com/users/ammaree/followers","following_url":"https://api.github.com/users/ammaree/following{/other_user}","gists_url":"https://api.github.com/users/ammaree/gists{/gist_id}","starred_url":"https://api.github.com/users/ammaree/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ammaree/subscriptions","organizations_url":"https://api.github.com/users/ammaree/orgs","repos_url":"https://api.github.com/users/ammaree/repos","events_url":"https://api.github.com/users/ammaree/events{/privacy}","received_events_url":"https://api.github.com/users/ammaree/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2018-02-22T19:35:06Z","updated_at":"2018-03-07T19:13:02Z","closed_at":null,"author_association":"NONE","body":"We are trying to understand the core dump module but need some clarity on a number of items. Some background first.\r\n\r\nWe have implemented a mechanism to track planned and unplanned (crash) restarts and to make an informed decision about automatically reverting to previous version of OTA firmware. Whenever an unplanned restart is detected the full core dump partition is uploaded to our cloud host using HTTP PUT functionality and uniquely identified using MAC address and time..\r\n\r\n[http://esp-idf.readthedocs.io/en/latest/api-guides/core_dump.html#save-core-dump-to-flash](url) states that the core dump size is the sum of all the TCBs and all the stacks, plus a small additional overhead. Based on this we calculated a core dump partitions of ~140KB, and for safety we made it 192KB.\r\n\r\nWe configured the coredump to use logging level 5, expecting the amount of info in the coredump to be  more, but similar to @nkolban in [https://www.esp32.com/viewtopic.php?f=13&t=1099](url) , found that only the log info prior/during the core dump generation increases, the amount of info in the coredump stays the same.\r\n\r\nQ1: How should we calculate the core dump partition size since 20 tasks with total of ~140k stack allocated only creates a core dump of ~16K ?\r\n\r\nQ2: What is the exact syntax required to enable the 'espcoredump.py' utility to take its input from the  uploaded binary file? We have tried using:\r\n\"python /c/Dropbox/devs/ws/z-sdk/esp-idf/components/espcoredump/espcoredump.py --chip esp32 info_corefile --core  /c/Dropbox/devs/ws/z-appl/ewm-irmacos/coredump/30aea432bc00_1.bin --core-format raw --print-mem\"\r\nand a number of variations on the above but the help message says:\r\n'usage: espcoredump info_corefile [-h] [--gdb GDB] [--core CORE]\r\n                                 [--core-format CORE_FORMAT] [--off OFF]\r\n                                 [--save-core SAVE_CORE] [--print-mem]\r\n                                 prog\r\nespcoredump info_corefile: error: too few arguments\"\r\n\r\nThe \"prog\" parameter is not documented anywhere but from the python source it appears to be the path to the ELF file.\r\n\r\nAdding the path [+filename] to the command line causes an error message:\r\n\"Growing up stacks are not supported for now!\r\nFailed to create corefile!\"\r\n\r\nWhat parameters are we missing or have wrong?\r\n"},"comment":{"url":"https://api.github.com/repos/espressif/esp-idf/issues/comments/371250803","html_url":"https://github.com/espressif/esp-idf/issues/1650#issuecomment-371250803","issue_url":"https://api.github.com/repos/espressif/esp-idf/issues/1650","id":371250803,"user":{"login":"gerekon","id":25152166,"avatar_url":"https://avatars0.githubusercontent.com/u/25152166?v=4","gravatar_id":"","url":"https://api.github.com/users/gerekon","html_url":"https://github.com/gerekon","followers_url":"https://api.github.com/users/gerekon/followers","following_url":"https://api.github.com/users/gerekon/following{/other_user}","gists_url":"https://api.github.com/users/gerekon/gists{/gist_id}","starred_url":"https://api.github.com/users/gerekon/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gerekon/subscriptions","organizations_url":"https://api.github.com/users/gerekon/orgs","repos_url":"https://api.github.com/users/gerekon/repos","events_url":"https://api.github.com/users/gerekon/events{/privacy}","received_events_url":"https://api.github.com/users/gerekon/received_events","type":"User","site_admin":false},"created_at":"2018-03-07T19:13:02Z","updated_at":"2018-03-07T19:13:02Z","author_association":"CONTRIBUTOR","body":"@ammaree \r\n> http://esp-idf.readthedocs.io/en/latest/api-guides/core_dump.html#save-core-dump-to-flash states that the core dump size is the sum of all the TCBs and all the stacks, plus a small additional overhead. Based on this we calculated a core dump partitions of ~140KB, and for safety we made it 192KB.\r\n\r\nCore dump module saves only that part of task's stack which is actually used at the moment of crash. So dump data size is much smaller than theoretical maximum.\r\n> Q1: How should we calculate the core dump partition size since 20 tasks with total of ~140k stack allocated only creates a core dump of ~16K ?\r\n\r\nHaving in mind optimization mentioned above I see the following possible approaches:\r\n\r\n- Using stack debug watchpoint. Enable `Set a debug watchpoint as a stack overflow check` item in `Component config->FreeRTOS`. For every task sequentially decrease stack size, run the tests. If tests have passed repeat again. The stack size at which watchpoint is triggered is the minimal space to be reserved for that task. \r\n- Using FreeRTOS API. OS provides `uxTaskGetStackHighWaterMark()` function which can be used to find minimal space size necessary to store every task's stack.\r\n\r\nWhen calculating core dump partition size you can add additional space to the minimal one for every task, for example by multiplying it by 1.15 coef. So the formula should look like `part_size = small_overhead_size + tcbs_size + 1.15*(min_stack_sz_task_1 + ... + min_stack_sz_task_N)`.\r\n> Q2: What is the exact syntax required to enable the 'espcoredump.py' utility to take its input from the uploaded binary file?\r\n\r\nCommand syntax for this: `espcoredump.py info_corefile -c <path_to_core_file> -t raw <path_to_prog_elf_file>`. Note that you should remove the first 4 bytes from the raw data read from flash to use that python script."}}
{"actor":{"display_login":"gerekon"}}