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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user

Reply via email to