• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 834 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Hwi and TIRTOS

julien1986
Intellectual 385 points
Other Parts Discussed in Thread: MSP430FR5969, SYSBIOS

Hi,

I'm working on the MSP430FR5969 with TIRTOS 2.10.1.38. I have imported the empty project(not the minimal).

I have enabled the GPIO interrupt. So when I have an interrupt my code go to the function  ti_sysbios_family_msp430_Hwi0(Void) in HwiFuncs.c . I have seen that this file is generated by TIRTOS during the compilation.

I don't want to use these functions and this file. I want to create my own function from the config file(See the window below)

I have found nothing about how to disable this files and this function...

Thanks for the help

Julien

  • 0
    TI__Mastermind 26780 points

    Julien,

    If you are building a SYS/BIOS application it is strongly recommended to start with the minimal or some other SYS/BIOS example template.  If you start from empty or completely from scratch it will probably be a challenge to get all the different pieces properly configured.

    Regarding the interrupt stubs generated in HwiFuncs.c… By default there is an interrupt stub generated for each CPU interrupt to trap unintentional interrupts.  You can disable these traps with the graphical tool, or by adding this line to you application's .cfg file:

    Hwi.fillVectors = false;

    There is more information here: processors.wiki.ti.com/.../BIOS_for_the_MSP430;  You may want to look at other sections of that wiki page for background of why these interrupt stubs are generated, and why they are necessary if an interrupt service routine readies a thread to run (for example, by posting a Semaphore).

    When you set Hwi.fillVectors to false, this HwiFuncs.c file may go away.  But if you have timing services configured (a SYS/BIOS Timer or Clock), then this file will still exist, but with only the relevant interrupt stubs generated for the timer interrupt(s).

    If you want to create and place your own ISR you can do this (as described here: processors.wiki.ti.com/.../BIOS_for_the_MSP430).  Note this is done independently in your application source code, and you wouldn’t be configuring this interrupt with SYS/BIOS.

    Regards,
    Scott

  • 0 in reply to ScottG
    Intellectual 385 points

    Hi Scott,


    Thanks for your answer.

    I have made a mistake in my post. I have started with the typical project in the TI target example (see below)

    But I think It’s not the great choice and now I want to use the Minimal project. The Dynamic memory allocation doesn’t need to enable. I have tried to compile this code but there is an error

    "../lnk_msp430fr5969.cmd", line 175: error #10099-D: program will not fit into available memory.  run placement with alignment fails for section ".data" size 0x3ca .  Available memory ranges:
       RAM          size: 0x800        unused: 0xf0         max hole: 0xf0      
    error #10010: errors encountered during linking; "Project_light.out" not built.

    Have you ever seen this error?  I think there is an error in the linker cmd file.

    About the interrupt ISR I didn't understand that the ISR functions created in the config file are called in the HwiFuncs.c file.  I understand now that I can declare my own isr function from the config file. Then create it in C file. This function will be automatically called by the function in HwiFunc file.

  • 0 in reply to julien1986
    TI__Mastermind 26780 points

    Hi Julien,

    OK, thanks.  That link error is a known issue on this device.  You’ll need to tweak the linker command file in your project to get around it (for example, allow placement of .bss into either RAM or FRAM). 

    Please see this forum post for more details: e2e.ti.com/.../1471711

    Thanks,
    Scott