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.

.vecs section and SYS/BIOS

Other Parts Discussed in Thread: SYSBIOS

Hello,

I try to find a way to avoid SYS/BIOS generating a specific INT vector for the 64x+ DSP. The CCS v6 and SYS/BIOS 6.40.1.15 generate a section named .vecs with all the vectors defined (the section size is 0x200 bytes). I use a custom communication kernel which uses the INT4 and this vector must be kept as is and must not be managed by SYS/BIOS. I do not found any way to keep the original vector as is even if this INT is not used or declared in SYS/BIOS. Any suggestion?

Thank.

  • Hi,

    Moving your post to right forum to be better answered.

    Thanks & regards,

    Sivaraj K

  • The Hwi_plug(intnum, isrFunc) API allows you to plug a vector at runtime with your own ISR function. Would this be satisfactory?

    Alan

  • Thank Alan.

    I would like to try but I can't find any documentation about the Hwi_plug() API function. I have the spru403s.pdf (DSP/BIOS) API reference guide which does not include this function but a similar function called C64_plug.

    Also, I use the last version of the SYS/BIOS (6.40.1.15) and I can't find the API reference guide for this version. For instance, I would like to know if I have to create a HWI instance or something before the call of the function Hwi_plug() in my code and also what are the conditions.

    Alex

  • The CDOC html files provide the most detailed and current description of APIs.

    In the root directory of your SYS/BIOS installation, within the "docs\cdoc\" directory, click on the index.html file. Within this first page, click the 'ti.sysbios.family.c64p' package. Then click on the 'Hwi' module. Then click on the Hwi_plug() function.

    There is no need to create a Hwi instance to use Hwi_plug(). However you will have to cast the ISR function to be of type 'Hwi_PlugFuncPtr'

    Alan

  • Thank for the information. I did the Hwi_Plug() call in my code but it does not work. I have to specify a constant for the ISR address since it is a kernel code not linked to my project. I did my call like this:

    Hwi_plug(4, (Hwi_PlugFuncPtr)0x10E08200);

    My vector (.vecs) section is in the L1P memory not accessible by the CPU. A DMA must be used by the CPU to allow a write in the L1P. Do you know if the Hwi_plug can write the IST located in the L1P? May be this is my problem.

    Alex

  • You might try statically plugging the vector table using Hwi.plugMeta() in your config file:

        var c64pHwi = xdc.useModule('ti.sysbios.family.c64p.Hwi');

        c64pHwi.plugMeta(4, isrFunctionLabel);

    Alan

  • Another possible problem with the Hwi_Plug() API function: as describe in the function documentation, the assembler code used to create the IST for the ISR is:

    STW  B0,SP--[1]
    MVK  fxn,B0
    MVKH fxn,B0
    B B0
    LDW *++SP[1],B0
    NOP 4

    The problem I see with this code is that the SP is not aligned on a double word anymore during the ISR routine execution. My ISR routine uses STDW instruction and considers that the SP is aligned on a double word. When I define a IST, I normally use this code to keep the SP aligned:

    STW .D2T2 B10,SP--[2]
    || MVKL .S2 _SR3AIC,B10
    MVKH .S2 _SR3AIC,B10
    B .S2 B10
    LDW .D2T2 *++SP[2],B10
    NOP 4
    NOP
    NOP

    Alex

  • As I said before, the function label does not exist in my project. The ISR function is a resident kernel code. I know the absolute address which is 0x10E08200.

    Alex

  • Hello,

    I'm still thinking about the problem I have with the .vect section and the runtime solution you suggested (Hwi_plug()) not possible for us. Actually, the communication kernel code we have developped provides the USB communication functionality to load the DSP code and to launch at _c_int00. If the .vecs section contains an empty vector for the INT4 interrupt, the loader supported by our communication kernel will stop working after the load of the .vecs section. So, I have to do it statically with the SYS/BIOS .cfg file. I'm still not able to indicate the ISR function address because it is not a function of the project but a fixed address of our kernel (in this case 0x10E08200). Any suggestions to specify a fixed address for the c64pHwi.plugMeta(4, isrFunctionLabel) in the cfg file?

    Alex

  • I found a solution to define the INT4 vector statically with c64pHwi.plugMeta(). I define a new function in my project which calls my original ISR function which is in resident kernel code. I use the constant address of the kernel function. However, I have another problem with this approach: the loader starts with the load of the .vecs section (which appears first in the COFF file). Since the loader uses the INT4 interrupt, the DSP crashes since the function of my project is not loaded yet. I manually changed the load order it works. But this is not a safe solution. Somebody can explain me the way to use the c64pHwi.plugMeta() in the sys/bios CFG file with a constant address?


    Alex

  • Alex,

    I've tried a bunch of different ideas but so far have not found a way to coerce Hwi.plugMeta() into accepting a literal address as an argument.

    Alan

  • Alan,

    Thank for the feedback. I have found a workaround: I intercepts the .vecs section while I extract the COFF file and I replace the INT4 vector with the correct one. It works but this is not the most elegant approach...

    Alex

  • Alex,

    I'm sorry I couldn't help much with this.

    Can you mark yourself as answering this thread please? You'll get extra points if you do. :-)

    Alan

  • The linker lets you define symbols. I'm at home so I don't have the docs, but it's doable. Define your symbol for that address, declare the ISR with that name in the C,, and the compiler and linker will join the dots for you.
  • Hello Graham,

    Thank for the feedback. It makes sense but I'm not able to make it work... I tried this:

    In my main.c:

    #define ISRKernel 0x10E08200

    void ISRKernel();

    The compiler says expected an identifier...

    Alex

  • It will do, because you're defining a pre-processor macro there, not a linker symbol. :)

    Declare "extern interrupt void ISRKernel();" so that your C code has something to work with.  I'm not sure whether the declaration really needs the "interrupt" keyword if you don't have a definition elsewhere in the file, but some compilers do need it and other compilers will just ignore it if they don't need it, so it's generally safer.

    Then you use the linker command file to set (at link time) where the code thinks ISRKernel lives.  Check out the TI datasheet SPRU186W section 7.5.8 for details of how to do this.  It should be as simple as "ISRKernel = 0x10E08200;".  Being naturally sceptical, I would check the MAP file afterwards to make sure ISRKernel is listed and set correctly.

    If you don't already have a linker command file, it's easy enough to set one up.  Section 7.5 of SPRU186W covers it, but you won't need most of that for what you're doing here.  The main gotcha is just that it needs "MEMORY" and "SECTIONS" definitions in the file, even if they're empty.

  • Hello Graham,

    It works! I have to define the ISRKernel in my CMD with an underscore _ISRKernel = 0x10E08200;. The map file includes the symbol and I have checked on my DSP board and it works.

    Many thanks!

    Alex

  • Cool - glad it's sorted. :)