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