• State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 22 subscribers
  • Views 934 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

XC866 - Paging causes to unexpected jump

Stefan Fricke

Hi all,

I am a newbie in 8-bit programming related to
8051 based devices.

Can somebody of the professionals help me in the following case ?

/* These is extracted from MAIN.H file,
   which DAvE has generated
*/
//   CCU6_PAGE
#define _cc0 CCU6_PAGE=0 // CCU6_PAGE postfix
#define _cc1 CCU6_PAGE=1 // CCU6_PAGE postfix
#define _cc2 CCU6_PAGE=2 // CCU6_PAGE postfix
#define _cc3 CCU6_PAGE=3 // CCU6_PAGE postfix
// Save/Restore
#define SST0  0x80        // Save SFR page to ST0
#define RST0  0xC0        // Restore SFR page from ST0
#define SST1  0x90        // Save SFR page to ST1
#define RST1  0xD0        // Restore SFR page from ST1
#define SST2  0xA0        // Save SFR page to ST2
#define RST2  0xE0        // Restore SFR page from ST2
#define SST3  0xB0        // Save SFR page to ST3
#define RST3  0xF0        // Restore SFR page from ST3
#define noSST 0x00        // Switch page without saving
// Switch a page
#define SFR_PAGE(pg,op) pg+op

//--- in main() ---
...
	MAIN_vInit();

  	SFR_PAGE(_cc2,SST3);
	   CCU6_ISSL |= 0x80;
	SFR_PAGE(_cc0,RST3);
...
//---

MAIN_vInit() does a setup for CCU6
(aka CAPCOM6) which enables an interrupt
for period match.
CCU6_ISSL |= 0x80 triggers this interrupt by software.
( Or should do this. )

The page switching is right done as I checked, but have a look at disassembly window I got

C:0x171F    D1CB     ACALL    MAIN_vInit(C:16CB)
   460:   SFR_PAGE(_cc2,SST3);
C:0x1721    75A3B2   MOV      CCU6_PAGE(0xA3),#PORT_PAGE(0xB2)
   461:            CCU6_ISSL |= 0x80;
C:0x1724    43A480   ORL      CCU6_T12DTCL(0xA4),#P0_DATA(0x80)
   462:         SFR_PAGE(_cc0,RST3);
   463:
C:0x1727    75A3F0   MOV      CCU6_PAGE(0xA3),#B(0xF0)
and single stepping the ORL instruction I recognized, I will arrive at

C:0x006C 00 NOP
C:0x006D 026000 LJMP C:6000
C:0x0070 00 NOP
C:0x0071 00 NOP

what seems to me that I am, however, jumping
to startup code.
So I can not check at this moment, whether the ISSL is OR-ed right.

Has anybody an idea, what goes wrong here ?
Any idea, help, enlighting is welcome,
since I spend a whole day with different debug sessions and have no idea anymore.
( Hope it is not so difficult for the experts in this forum )

Using: C51 latest (beta) release and DAvE

Thanks Stefan

Parents
  • 0

    Hi all,

    this problem could be solved .
    It seems that in this case the DAvE is
    the reason of the evil.

    DAvE generates following wrongdefines for the vector numbers:

    #define   CCU6_NodeI0_INT	16
#define   CCU6_NodeI1_INT       17
#define   CCU6_NodeI2_INT       18
#define   CCU6_NodeI3_INT       19
    which must be correct:
    #define   CCU6_NodeI0_INT	10
#define   CCU6_NodeI1_INT       11
#define   CCU6_NodeI2_INT       12
#define   CCU6_NodeI3_INT       13

    So I jumped correct to the Node2 vector,
    but through the wrong numbers above the
    LJMP to the ISR was placed wrong.

    Thanks to Reinhard Keil for the important hint concerning the vector 0x0063 I did
    not take care about.

    Stefan

Reply
  • 0

    Hi all,

    this problem could be solved .
    It seems that in this case the DAvE is
    the reason of the evil.

    DAvE generates following wrongdefines for the vector numbers:

    #define   CCU6_NodeI0_INT	16
#define   CCU6_NodeI1_INT       17
#define   CCU6_NodeI2_INT       18
#define   CCU6_NodeI3_INT       19
    which must be correct:
    #define   CCU6_NodeI0_INT	10
#define   CCU6_NodeI1_INT       11
#define   CCU6_NodeI2_INT       12
#define   CCU6_NodeI3_INT       13

    So I jumped correct to the Node2 vector,
    but through the wrong numbers above the
    LJMP to the ISR was placed wrong.

    Thanks to Reinhard Keil for the important hint concerning the vector 0x0063 I did
    not take care about.

    Stefan

Children
  • 0 in reply to Stefan Fricke

    The DAvE users could use as workaround the following entries in CC6.H

    Notice the as usual the
    // USER CODE BEGIN
    and
    // USER CODE END
    labels from/for DAvE

    //****************************************************************************
// @Interrupt Vectors
//****************************************************************************

#define CCU6_NodeI0_INT 16
#define CCU6_NodeI2_INT 18


// USER CODE BEGIN (CCU6_Header,10)

/*
   DO HERE : for all CCU6_NodeIx_INT 's
             to be sure that they are not
             overwritten by a DAvE refresh
             or regenerating code
             ( or if you want to use more
               Nodes in future )
*/

#undef  CCU6_NodeI0_INT
#define CCU6_NodeI0_INT 10
#undef  CCU6_NodeI1_INT
#define CCU6_NodeI1_INT 11
#undef  CCU6_NodeI2_INT
#define CCU6_NodeI2_INT 12
#undef  CCU6_NodeI3_INT
#define CCU6_NodeI3_INT 13

// USER CODE END

    Stefan

  • 0 in reply to Stefan Fricke

    Hi all,

    this problem is fixed with the new DIP V1.4,
    available at Infineon WEB-site.
    Users of DIP V1.3 should it update.

    Stefan