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

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

Dear 

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)

OR

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

Thanks,

Parents
  • 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.(https://renesasrulz.com/mcu-mpu/rl78/f/rl78-forum/28352/sample-code-for-how-to-divide-boot-and-flash-areas-document)

    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.

    app.zip

    3051.bl.zip

  • 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.

Reply
  • 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.

Children
  • 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=)?

    Thanks,

  • I finally got some time to look into this.  There are several things going on with tools under the hood that are not obvious.  If you enable assembler source or assembler listing and have a look at the assembly file you will notice a few things:

    Using the code generator for CS+ has the effect of not exporting the symbol (function name) as public because they are declared "static", and the symbol name is "mangled" by the compiler by appending the suffix "@1" to the symbol name. 

    The app-note makes a mention about not defining the interrupt vector number for the function:

    But I don't believe there is any way to control this in the code-generator.

    If you wish to continue to use the CS+ code generator with this application I believe you will have to manually edit the files to remove the "static" and the interrupt vector numbers from auto-generated code, there does not appear any mechanism or option to avoid this.

    Leaving the __near qualifier is simply a question of implementation.  If these functions are can be located lower 64KB these can remain, however I see no advantage since the jump-table must reference them as far jump in order to maintain the 4-byte table entry size.

  • Clear for me. 

    Thank you so much.