the file that contains main() was not linked first. Changing the order
did not fix the issue. Any other suggestions?
a*
Anthony Asterisk wrote:
> I'll check that out. Any idea why accessing this one variable would
> change the order? It seems totally random.
>
> Maarten Brock wrote:
>> Anthony,
>>
>> Are you linking the file that contains main() as the
>> first object? It looks like the linker has put
>> sdcc_call_dptr() at the address of the reset vector
>> which makes it jump to whatever A+DPTR is after reset.
>>
>> Maarten
>>
>>
>>> another strange observation. If I move the actual declaration of the
>>> sensors_event to a different file everything works. Unfortunately this
>>> is not a suitable long term solution.
>>>
>>> Anthony Asterisk wrote:
>>>
>>>> I hit a very frustrating problem yesterday and a solution is still
>>>> alluding me. Unfortunately the problem shows up when trying to
>>>> execute the linked ihx file on the target platform so it is not easy
>>>> for me to provide a testcase. I will give some code snippets, please
>>>> let me know any steps I can take to further debug it.
>>>>
>>>>
>>>> Here is the code that I am altering. A working version looks like this:
>>>>
>>>> printf("\n\npress button ");
>>>> etimer_set(&timer,CLOCK_CONF_SECOND/5);
>>>> while (1) {
>>>> PROCESS_WAIT_EVENT();
>>>> if (ev==PROCESS_EVENT_TIMER) {
>>>> etimer_reset(&timer);
>>>> lcd_putchar(0x08);
>>>> lcd_putchar(spin[spin_ptr]);
>>>> spin_ptr = (spin_ptr+1)%4;
>>>> }
>>>> else if (ev==PROCESS_EVENT_MSG) {
>>>> //else if (ev == sensors_event) {
>>>> exp_port.fields.leds++;
>>>> }
>>>> else {
>>>> printf("unknown event\n");
>>>> }
>>>> }
>>>>
>>>> With this code the message "press button" is displayed.
>>>>
>>>> If I switch the commented lines ONLY, press button is never displayed
>>>> and it seems like nothing is even loaded/executed on the target platform.
>>>>
>>>> printf("\n\npress button ");
>>>> etimer_set(&timer,CLOCK_CONF_SECOND/5);
>>>> while (1) {
>>>> PROCESS_WAIT_EVENT();
>>>> if (ev==PROCESS_EVENT_TIMER) {
>>>> etimer_reset(&timer);
>>>> lcd_putchar(0x08);
>>>> lcd_putchar(spin[spin_ptr]);
>>>> spin_ptr = (spin_ptr+1)%4;
>>>> }
>>>> //else if (ev==PROCESS_EVENT_MSG) {
>>>> else if (ev == sensors_event) {
>>>> exp_port.fields.leds++;
>>>> }
>>>> else {
>>>> printf("unknown event\n");
>>>> }
>>>> }
>>>>
>>>>
>>>> The extern declaration of sensors_event is in an included header
>>>> file. It looks like this:
>>>>
>>>> extern process_event_t sensors_event;
>>>>
>>>> And the actual declaration (in a code file) looks like this:
>>>>
>>>> process_event_t sensors_event;
>>>>
>>>>
>>>> Nothing surprising there.
>>>>
>>>>
>>>> I've been digging around in the *.sym and linker output *.map file for
>>>> some clue.
>>>>
>>>> In the *.sym file for the module with the code snippet above I see:
>>>>
>>>> _sensors_event
>>>> **** GX
>>>>
>>>>
>>>> In the aslink output *.map file, I see:
>>>>
>>>> Hexadecimal
>>>>
>>>> Area Addr Size Decimal Bytes
>>>> (Attributes)
>>>> -------------------------------- ---- ---- ------- -----
>>>> ------------
>>>> XSEG E000 0291 = 657. bytes
>>>> (REL,CON,XDATA)
>>>>
>>>> Value Global
>>>> -------- --------------------------------
>>>> 0D:E010 _exp_port
>>>> 0D:E016 _ddram_addr
>>>> 0D:E017 _sensors_event
>>>> 0D:E10D _p0ien
>>>> 0D:E10E _p2ien
>>>>
>>>>
>>>> If I diff the *.map from the working and non-working version, the
>>>> results are very similar. The order of several various changes but
>>>> they are all still present. One change that I did notice which has me
>>>> wondering:
>>>>
>>>>
>>>> 431,432c431,432
>>>> < 0C:0000 __sdcc_call_dptr
>>>> < 0C:0088 __sdcc_program_startup
>>>> ---
>>>>
>>>>> 0C:0086 __sdcc_program_startup
>>>>> 0C:008B __sdcc_call_dptr
>>>>>
>>>> these differences are here:
>>>>
>>>> Area Addr Size Decimal Bytes
>>>> (Attributes)
>>>> -------------------------------- ---- ---- ------- -----
>>>> ------------
>>>> HOME 0000 008D = 141. bytes
>>>> (REL,CON,CODE)
>>>>
>>>> Value Global
>>>> -------- --------------------------------
>>>> 0C:0000 __sdcc_call_dptr
>>>> 0C:0088 __sdcc_program_startup
>>>>
>>>> Hexadecimal
>>>>
>>>>
>>>>
>>>>
>>>> The working version seems to have a non-null address for the
>>>> __sdcc_call_dptr code, but the broken version has NULL. 0000 seems to
>>>> me like it might indicate some sort of error.
>>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>>> trial. Simplify your report design, integration and deployment - and focus on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now.http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> Sdcc-user mailing list
>>> Sdcc-user@...
>>> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>>>
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Sdcc-user mailing list
>> Sdcc-user@...
>> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>>
|