i am working with the U-cosII and i create a simple four tasks that blink the led at the different rate, i had sucessfully build the hex and downlod on the lpc2148 target board. and i had achive my o/p. for the above build i have used the arm-elf-gcc 4.0.1. Now after some time i download the newer version of the arm-elf-gcc 4.0.2 and i tried to build the above porject. I didn't get0 any error while compliing and hex is also generated. and i download the hexfile to the same target but i didn't get the o/p,means all leds are set at their default state. please help me to resolve the above porblem. hoping for the reply, thankyou
It seems unlikely that it is an issue with the version of GCC (or at least this is the least likly cause). It is more likely that your code has memory error. When a memory corruption occurs the results are non-deterministic; it will depend what gets corrupted and when and how the corrupted data is subsequently used. By building with a different tool, the code is likely to have a different memory organisation and timing. So wheras before the corruption was benign or unobservable, it is now causing a failure. Causes of such errors include; * stack overflow, * buffer overrun, * array bounds error, * unitialised pointer, * unchecked memory allocation error. They are amongst the hardest to erors to debug. You may need to post your code to get more help. You should at least check that each task has sufficient stack allocation, taking into account any library calls you make; printf() for example requires a significant ammount of stack. If your stacks are allocated dynamicaly, you need also to ensure that you have a working sbrk_r() implementation, and that you have sufficient heap space. Clifford
Thankyou for reply what should i do for my code should i change the linker file for the code? and again complie? hoping for reply
pragnesh wrote: > what should i do for my code should i change the linker file for the > code? What for!? We have not yet determined what the problem is. If as I suggested it is an error in your code, then you need to find and fix the error. The linker script is unlikely to be the issue. The size of the interrupt stack will be important when using an RTOS since the system tick and sheduling will run in the interrupt context. Depending on your BSP the kernel may switch from IRQ to Supervisor mode during interrupt processing, so you will need to ensure you have enough of both - check teh documentation for the processor port you are using; in uC/OSII most processor specific ports are provided by third parties, so it is not possible for me to determine teh requirements in your case - unless you provide details of the port you are using. Task stacks are separately allocated at run time, rather than being set by the linker or the C runtime startup code - the system stack is only important for the code that runs before you start the sheduler. Of course, if you allocated these stacks from the system stack as local array variables(a bad idea) then the system stack is important. Normally you would use a static array or dynamically allocate the stacks from the heap. For small systems with tight memory resources where tasks are not dynamically created and destroyed, static allocation is normally prefereable. As I suggested before, it is impossible to say what the problem might be unless you post the code. Have you tried just starting one task at a time? Of course if you are sure the code is fine (which I still doubt), then you could always just stick with 4.0.1. There is probably no real justification for migrating on such a minor increment. Martin Thomas has worked hard to produce leading edge GCC builds (a service that most other distributions charge for), and for some this is essential; but the embedded systems market is rather conservative; most commercial distributions are still based on 3.2 or 3.4, because for mission critical tasks you want a mature release that has had all necessary target specific patches applied. Clifford
Just an additional idea: Newer versions of a compiler usualy have better optimization strategies. For example: maybe a forgotten volatile in the source has never been noticed before because the optimizer of an older version did not use a "core-register" as temporary storage but created instructions to always read/write the memory. Martin Thomas
Martin Thomas wrote: > Just an additional idea: Newer versions of a compiler usualy have better > optimization strategies. For example: maybe a forgotten volatile in the > source has never been noticed before because the optimizer of an older > version did not use a "core-register" as temporary storage but created > instructions to always read/write the memory. > > Martin Thomas Thank you sir your suggestion is very helpful to me. i have solved my problem in my previous code i change the variable to the "volatile". Thank you very much for your suggestion.