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.

OMAPL138/DA830 SPURIOUSINT HWI

Other Parts Discussed in Thread: SYSBIOS

 Hi Bios Team

Debugging a customer issue, where they are reporting the following behavior

---

The image is using the following version:

- CCS Version 5.2.1.00018

- SYS/BIOS 6.30.03.46 (eabi) ELF

- TMS470 Code Generation Tools 4.9.6

- XDCTOOLS 3.23.03.53

 

The ARM code is running in SHARED RAM and in the ARMs local RAM, no code in the DDR2.

To the outside world USB0 is used (as a device). 

When I run the test with emulator and without the USB0 connected to my Laptop everything works fine.

When I run the test with emulator and the USB0 connected to my Laptop (LabView is sending every second a debug cmd via USB to the ARM to retrieve the status/progess) it takes some iterations and then I can that the spuriousInt is called.

----

Can someone please point me to where more information can be found on spuriousint and possible causes for it.

 

  • Mukul,

    The Hwi_spuriousint() function gets called as a default interrupt function when an interrupt was enabled but without having a vector function pointer assigned to it.

    My guess would be that the interrupt for a particular vector was enabled, without actually having created a Hwi for it.

    You could find the Host Interrupt Priority Index Register in CCS (not sure if that's the exact name) to determine which interrupt vector was generated when you're sitting in the Hwi_spuriousint() function.

  • Mukul,

    The below sequence of code seems correct for hardware interrupt in the cfg file.
    Static:
    var ti_sysbios_family_arm_da830_Hwi = xdc.useModule('ti.sysbios.family.arm.da830.Hwi');
    ti_sysbios_family_arm_da830_Hwi.vectorTableAddress = 0xffff0040;

    var instti_sysbios_family_arm_da830_Hwi7Params0 = new ti_sysbios_family_arm_da830_Hwi.Params();
    instti_sysbios_family_arm_da830_Hwi7Params0.enableInt = false;
    instti_sysbios_family_arm_da830_Hwi7Params0.instance.name = "USB0_INT";
    instti_sysbios_family_arm_da830_Hwi7Params0.priority = 4;
    Program.global.USB0_INT = ti_sysbios_family_arm_da830_Hwi.create(58, "&armUSB20Isr", instti_sysbios_family_arm_da830_Hwi7Params0);


    var ti_sysbios_family_arm_da830_Hwi1Params = new ti_sysbios_family_arm_da830_Hwi.Params();
    ti_sysbios_family_arm_da830_Hwi1Params.instance.name = "IIC0_INT";
    ti_sysbios_family_arm_da830_Hwi1Params.enableInt = false;
    ti_sysbios_family_arm_da830_Hwi1Params.priority = 4;
    Program.global.IIC0_INT = ti_sysbios_family_arm_da830_Hwi.create(15, "&armIIC0Isr", ti_sysbios_family_arm_da830_Hwi1Params);

    1. Please remove the vectorTableAddress line from the cfg file and test the same. ti_sysbios_family_arm_da830_Hwi.vectorTableAddress = 0xffff0040;

     If possible share the memory map file(.map) for analyze the same. 

    2. Another option,  we can create a Hwi object dynamically. Here "eb" is an error block.
    You can use to handle errors that may occur during Hwi object creation.

  • Hi Tom, Pubesh

    Thanks for the responses. I have asked the customer to look at these recommendations and test them out.

    Regards

    Mukul