Code generate without "vect" and "near" option for ISR


Could you let me know the way to generate the interrupt code without "vect" & "near" option?

#pragma interrupt r_tau0_channel0_interrupt(vect=INTTM00) ==>  #pragma interrupt r_tau0_channel0_interrupt

static void __near r_tau0_channel0_interrupt(void) ==> static void  r_tau0_channel0_interrupt(void)


Is there any way to branch into near area? 

Because when I add the BR command, I can see the error as follows.

It is only disappeared when I remove "near" option.

BR     !!_r_tau0_channel0_interrupt


  • The insn "BR  !!<addr>" is using the far-notation with 2x '!' in the operand.  For near-addressing use a single '!', i.e. "BR !<addr>".  From the RL78 Software U/M:

  • Thanks for your reply.

    But I can see the same errors. Please, help.

  • I'm sorry but it isn't clear to me what it is that you are trying to do.  The RL78 uses a vector table, executable code such as a branch insn cannot be put into the table.  As the table entries are only 16-bit, all ISR entry points must originate in "near" code (i.e. the lowest 64KB of flash memory).  From there one could implement a custom far-branch to where ever in the entire 20-bit "far" address space of the device.

  • Hi JimB,

    Thanks again.

    It is related with the ticket.(

    I'm trying to build a project that someone made and having this issue.

    Some instructions are displayed in the How To Boot and Flash area document.

    And it doesn't have __near option in the example.

    Could you review the code? There is no build error without code generation.

  • OK at least I understand the context of the branch table now.  I loaded both projects into CS+ and both built w/o errors.

    Since the RL78 doesn't support the concept of a vector base register where vectors can be relocated, the concept is to implement a jump-table in the application space where an interrupt is vectored to from the boot space.

    Consider the insn format of the unconditional branches:

    The format of the table is to implement the 4-byte BR to absolute 20-bit address.  Using the FFFFFFFF causes execution of the illegal opcode, which are the entries for unused interrupts.  Otherwise, the used interrupts need a jump to the real ISR implemented in the application.

    All symbols from the jump-table must be referenced as "far" or 20-bit addresses to maintain the table format, it does not matter whether the actual functions are placed in near memory, as a near address is the special case of a far address with the most-significant 4-bits assumed to be 0.

    This implementation of the application jump-table must be located in the lower 64KB of the flash address space (near addresses) because the ISR vector table only uses 16-bit addresses.  If the boot-loader was to take up more than 64KB of code, this implementation would need to change - there would need to be two jump-tables:  one the boot-loader to jump to the application and then the one in the application that jumps to the desired ISRs.

    Since the projects build w/o errors I cannot comment on what might be wrong with your implementation.  It is unfortunate that Renesas did not provide a working example project to demonstrate the concept.

  • So, every time I add any driver(UART,I2C, etc), Do I have to remove the vect and __near option?

    Appreciate your help.

  • Any time you add an ISR your jump-table for the application must include an entry for the ISR.  The jump table has no concept of interrupts or vectors, all it knows is to unconditionally branch to some address.  There should be no near / far references in the jump table as implemented in assembly code.  "BR  !!<IsrFunc>" is the table entry.

    The vector table in the bootloader should include the address for every hardware ISR implemented in the device.

  • Thanks a lot.

    When I click "generate code" button in application project, the ISR name has near. And It fails when I build.

    Because it generates the function name with "__near". 

    For fixing it, I need to remove it.

    So, I was asking that I have to remove the "__near" every time I add driver and click "generate code". like below.

    If yes, it is uncomfortable for me. That's why I'm finding another way for this issue.

    #pragma interrupt r_tau0_channel0_interrupt(vect=INTTM00) ==>  #pragma interrupt r_tau0_channel0_interrupt

    static void __near r_tau0_channel0_interrupt(void) ==> static void  r_tau0_channel0_interrupt(void)

  • OK now I understand your issue, with the code generator it always assumes that it has to follow the rules for RL78 where interrupt vectors must be located in the lower 64KB (near) address space so the vector table can reference it.

    If your boot-loader is larger than 64KB and the vectors are not able to be located in the lower 64KB, you will have to manually remove the "near" qualifier every time you generate code.

  • Really Sorry & Thanks,

    it seems that I didn't explain to you more in detail or I couldn't catch your comments.

    I'm asking about the sample projects that I uploaded.

    The sample bootloader has the 64KB size lower as below.

    *** Total Section Size ***

    RAMDATA SECTION: 00000200 Byte(s)
    ROMDATA SECTION: 000004d0 Byte(s)
    PROGRAM SECTION: 0000094c Byte(s)

    And when I build the application project without clicking "Generate Code" there is no error.

    After that, I clicked the "Generate Code" and it changes the original codes like below.

    #pragma interrupt r_tau0_channel0_interrupt ==>  #pragma interrupt r_tau0_channel0_interrupt(vect=INTTM00) 

    static void  r_tau0_channel0_interrupt(void) ==> static  void __near r_tau0_channel0_interrupt(void) 

    And occurred errors during build.

    According to your comments, if the bootloader size is lower than 64KB, the vector can be located in the lower 64KB(near). But it fails when the ISR has __near option.

    For me, when I make my own application, I have to remove the __near option when every time I click "Generate Code". It's very uncomfortable. 

    1. Are there any way to fix this issue without modifying the auto-generated options(__near,vect=)?