|
|||||||||||||||
FreeRTOS Support ArchiveThe FreeRTOS support forum is used to obtain active support directly from Real Time Engineers Ltd. In return for using our top quality software and services for free, we request you play fair and do your bit to help others too! Sign up to receive notifications of new support topics then help where you can.
Loading
Still puzzling over nasty stack corruptionPosted by Christian Koerber on August 14, 2006 Hi, I'm still puzzling over my corrupted stack. I have tracked the issue down until the portRESTORE_CONTEXT becomes expanded: System Info: - Atmel SAM7s256 64k RAM, 256k ROM - Everything in ThUMB mode but startup, ARM7 parts of FreeRTOS and possibly interrupts - The stack of the first TASK is inspected with void MemTrace( u32* adress, short nElements) { for( unsigned int i = 0; i < nElements; i++ ) TRACE("0x%lx + %d: 0x%lx\r\n", adress, i * 4, adress ); } The stack looks fine after creation of the task. The order of the functions which are called before the first task is started is, to my knowledge: Function File Mode Stack vTaskStartScheduler() tasks.c THUMB OK xPortStartScheduler() port.c THUMB OK vPortISRStartFirstTask() portISR.c ARM ? portRESTORE_CONTEXT portmacro.h ARM ? vATaskMCP() Task_MCP.c THUMB NOK Note that vPortISRStartFirstTask() is just expanding the portRESTORE_CONTEXT assembler macro. So directly before vPortISRStartFirstTask() the stack looks like: 0x209e4c + 0: 0xa5a5a5a5 0x209e4c + 4: 0xa5a5a5a5 ... 0x209e4c + 1924: 0xa5a5a5a5 0x209e4c + 1928: 0x0 0x209e4c + 1932: 0x3f 0x209e4c + 1936: 0x0 0x209e4c + 1940: 0x1010101 0x209e4c + 1944: 0x2020202 0x209e4c + 1948: 0x3030303 0x209e4c + 1952: 0x4040404 0x209e4c + 1956: 0x5050505 0x209e4c + 1960: 0x6060606 0x209e4c + 1964: 0x7070707 0x209e4c + 1968: 0x8080808 0x209e4c + 1972: 0x9090909 0x209e4c + 1976: 0x10101010 0x209e4c + 1980: 0x11111111 0x209e4c + 1984: 0x12121212 0x209e4c + 1988: 0x20a618 0x209e4c + 1992: 0xaaaaaaaa 0x209e4c + 1996: 0x10e035 I understand that the portRESTORE_CONTEXT macro does, in this case, nothing else but start the first task. Since all tasks but the one I'm inspecting were suspended, execution should resume in this task. The first thing I do in this task is looking at my stack. Doing this must alter the stack to some degree of course, but in, ahem, an ordered manner (sorry, can't put it any better)? Now the stack looks like this: 0x209e4c + 0: 0xa5a5a5a5 0x209e4c + 4: 0xa5a5a5a5 ... 0x209e4c + 132: 0xa5a5a5a5 0x209e4c + 136: 0x2 0x209e4c + 140: 0x78 0x209e4c + 144: 0x113f59 0x209e4c + 148: 0x2004e8 0x209e4c + 152: 0xa5a5a5a5 0x209e4c + 156: 0x20a450 0x209e4c + 160: 0x78 0x209e4c + 164: 0x20a5d0 0x209e4c + 168: 0x6 0x209e4c + 172: 0x20a408 0x209e4c + 176: 0x2 0x209e4c + 180: 0x20a3a8 0x209e4c + 184: 0x121443 0x209e4c + 188: 0x11278d 0x209e4c + 192: 0x121443 0x209e4c + 196: 0x11307b 0x209e4c + 200: 0xa5a5a5a5 0x209e4c + 204: 0x2004ec 0x209e4c + 208: 0x0 0x209e4c + 212: 0x20a407 0x209e4c + 216: 0x10 0x209e4c + 220: 0x16 0x209e4c + 224: 0x0 0x209e4c + 228: 0xffffffff 0x209e4c + 232: 0x1217a8 0x209e4c + 236: 0x0 0x209e4c + 240: 0xffffffff 0x209e4c + 244: 0x20a5d0 0x209e4c + 248: 0xa5a5a5a5 ... 0x209e4c + 1360: 0xa5a5a5a5 0x209e4c + 1364: 0x121441 0x209e4c + 1368: 0x2 0x209e4c + 1372: 0x20a407 0x209e4c + 1376: 0x6 0x209e4c + 1380: 0xa5a5a5a5 ... 0x209e4c + 1456: 0xa5a5a5a5 0x209e4c + 1460: 0x35613561 0x209e4c + 1464: 0x31363533 0x209e4c + 1468: 0x20a3a0 0x209e4c + 1472: 0x0 0x209e4c + 1476: 0x0 0x209e4c + 1480: 0xa5a5a5a5 0x209e4c + 1484: 0xa5a5a5a5 0x209e4c + 1488: 0xa5a5a5a5 0x209e4c + 1492: 0xa5a5a5a5 0x209e4c + 1496: 0xa5a5a5a5 0x209e4c + 1500: 0xa5a5a5 0x209e4c + 1504: 0x8080808 0x209e4c + 1508: 0x9090909 0x209e4c + 1512: 0x10101010 0x209e4c + 1516: 0x11111111 0x209e4c + 1520: 0x121430 0x209e4c + 1524: 0x209e4c 0x209e4c + 1528: 0x1f4 0x209e4c + 1532: 0x7070707 0x209e4c + 1536: 0x113463 0x209e4c + 1540: 0x20a4cf 0x209e4c + 1544: 0xa5a5a5a5 0x209e4c + 1548: 0x7fffffe2 0x209e4c + 1552: 0xffff0208 0x209e4c + 1556: 0x20a4b4 0x209e4c + 1560: 0x7fffffff 0x209e4c + 1564: 0xa5a5a5a5 ... 0x209e4c + 1628: 0xa5a5a5a5 0x209e4c + 1632: 0x197 0x209e4c + 1636: 0x10efb9 0x209e4c + 1640: 0x30327830 0x209e4c + 1644: 0x63346539 0x209e4c + 1648: 0x31202b20 0x209e4c + 1652: 0x3a383436 0x209e4c + 1656: 0x33783020 0x209e4c + 1660: 0x33383733 0x209e4c + 1664: 0xd333337 0x209e4c + 1668: 0xa5a50000 0x209e4c + 1672: 0xa5a5a5a5 ... 0x209e4c + 1856: 0xa5a5a5a5 0x209e4c + 1860: 0x38 0x209e4c + 1864: 0x36 0x209e4c + 1868: 0x34 0x209e4c + 1872: 0x3a 0x209e4c + 1876: 0x40 0x209e4c + 1880: 0x4016 0x209e4c + 1884: 0x0 0x209e4c + 1888: 0x3a0c 0x209e4c + 1892: 0x0 0x209e4c + 1896: 0x20a5c4 0x209e4c + 1900: 0x1da 0x209e4c + 1904: 0x110407 0x209e4c + 1908: 0x121430 0x209e4c + 1912: 0x209e4c 0x209e4c + 1916: 0x778 0x209e4c + 1920: 0x778 0x209e4c + 1924: 0x4040404 0x209e4c + 1928: 0x5050505 0x209e4c + 1932: 0x6060606 0x209e4c + 1936: 0x10e03f 0x209e4c + 1940: 0x2020202 0x209e4c + 1944: 0x3030303 0x209e4c + 1948: 0x4040404 0x209e4c + 1952: 0x5050505 0x209e4c + 1956: 0x6060606 0x209e4c + 1960: 0x7070707 0x209e4c + 1964: 0x8080808 0x209e4c + 1968: 0x9090909 0x209e4c + 1972: 0x10101010 0x209e4c + 1976: 0x4040404 0x209e4c + 1980: 0x5050505 0x209e4c + 1984: 0x6060606 0x209e4c + 1988: 0x7070707 0x209e4c + 1992: 0xaaaaaaaa 0x209e4c + 1996: 0x10e035 I am clueless abou what is going on here. To me it looks as if something was hijacking my stack, but I have not the slightest hint who could be this. Any advices are appreciated. regards, Christian RE: Still puzzling over nasty stack corruptionPosted by Richard on August 14, 2006 Which compiler are you using? Can you zip up your project and send it to me? Use the email address from the FreeRTOS.org contact WEB page ( r __dot~ barry *AT* freertos ~dot org) rather than the sourceforge email address, otherwise the attachment will get stripped off. Regards.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|
|||||||||||||||
Latest News
NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.
Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019
Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.
View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.
Careers
FreeRTOS and other embedded software careers at AWS.
FreeRTOS Partners
