CC2640R2F: Use XDC to add an entry into the Vector Table

Hi Hester,

Could you comment on why you want to do it this way? When working with this device (and BLE in particular) it is recommended to use the TI provided drivers for peripherals such as the Watchdog. I would also advice to use the "hwiHal" when possible in the TI-RTOS configuration file.

Hi M-W

The reason I'm trying to avoid using the TI-provided drivers is that I'm working on a medical application and am using the watchdog as a catch-all for "some third-party code went wrong" and I'll have a hard time justifying this if I need to use third-party code to set it up, i.e. IntRegister or WatchdogIntRegister.

I've dug further into what's going on, and it gets more complicated because I'm using the XDC Startup.resetFxn to execute some time-critical code before the remaining initialisation steps are complete and main is called.  I'm setting up the watchdog within this resetFxn, and can see that XDC doesn't place anything into the vector table (which is first copied from flash to 0x2000000) until after the remaining initialisation steps, i.e. at main.  This explains the behaviour I've seen - the interrupt handler has not been registered by the time the interrupt occurs (I currently have a while(1) at the end of my resetFxn - if I move this into main instead it works fine).  To avoid this I really need my vector table set up with my interrupt handler before runtime.

I've searched through as much XDC stuff as I can get my hands on, and have found that the vector table is populated by XDC (looking at the XdcBuildOutput/package/cfg/app_ble_prm3.c file) with some default handlers "ti_sysbios_family_arm_m3_Hwi_excHandlerAsm__I".  Is there any way I can get XDC to put my interrupt handler in there instead?  

Thanks,

Hester

Hester, 

I see. Note that the "IntRegister" is really only hardware abstraction (what we call DriverLib). With that I mean that it is not really a driver, it is simply an register abstraction layer. 

As for the XDC, this tool really only builds the TI-RTOS part of the application. On the CC13xx/CC26xx devices, the default reset table is typically put down by the start up file (see source/ti/devices/cc26x0r2/startup_files). The TI-RTOS would take over when it's corresponding "reset" is called (_c_int00).  The startup "ResetISR" is also the common entry point of the device, before any TI-RTOS related code is run.

You could add in and override the library version of the startup file, this would also mean you can update the vector table as you want.

Hi M-W,

Yeah I understand it's an abstraction layer, but would still prefer to find a way round it if possible.  If not, then OK I just have to work harder on my justification :)

The issue with using the startup_iar file is that there is a linking failure because both that and XDC define ResetISR.  As a result I have not been able to build a project with both the startup and the XDC configuration in place.

Do you know if I can resolve this clash somehow?

Thanks,

Hester

Hester,

You could always just lift the register code out of the DriverLib API if you want (the code is given for each API in the documentation if you don't want to go looking in the c files). i would say it is a good justification as long as you can show that the source of the API do not add any specific lo logic or function to the register accesses (other than taking care of most of the bit shifts) :)

As for the reset vectors defined in the kernel build, I'm not sure you can get away from these in any easy way (other than manually hacking around what the TI-RTOS generates and replace it with your own. It also simply builds "only" a "sparse" table. To some extent, you could possibly get it to build a full resetVectorTable but as far as i can tell, it comes at the cost of setting the vectorTable=resetVectorTable.

I will try to look into this further, but I'm not sure there is a clean way to do what you want. 

As an alternative, you could try to implement the "Exception function" and "No ISR Function" yourself and see if you can handle the "error" yourself.

m3Hwi.excHandlerFunc = "&myFunc";
m3Hwi.nullIsrFunc = "&myFunc2";

Hi M-W,

I will have a play with those and see what I can get working, thanks.

Is there an easy way to find a list of the available m3Hwi properties? I've had a hard time finding out what can be done, let alone doing the right thing! I've not used XDC before this project and am finding it very hard to locate documentation and navigate the packages.

Thanks,

Hester

Hi Hester,

There is not really any good list of m3Hwi properties. The best source that I know of is the API documentation:

http://dev.ti.com/tirex/explore/node?node=ABCeS-j7lCHi4VDZqij7Kw__pTTHBmu__LATEST

Let me know if you are able to get something working by setting up the exc and null functions!

Hi M-W,

Thanks for the link, that's really useful and just what I've been looking for!

I've tried using m3Hwi.excHandlerFunc = "&WatchdogHC" but I can't see any difference.  When I inspect the flash and even the RAM based vector table I'm still seeing a default value in there - 0x1001C901 if that means anything to you.

I've seen through that link you've provided that the nvic and vnvic properties are available to XDC.  Would it be wishful thinking to wonder if they can be populated via the configuration file?  I've tried the obvious (to me) m3Hwi.nvic[2] = "&WatchdogHC" which results in an error "no element indexed [2]" but I haven't gone any further down this path yet.

Thanks,

Hester

Hi Hester,

As far as I've been able to figure out, the vector table put down by the XDC tool is not really configurable in the case where it is later copied into RAM. It seems that there might be possible to some degree when the vectorTable=resetVectorTable=0x0 but I would not recommend this approach as I think it will impact the rest of the software suite.

0x1001C901 is a ROM function, I don't know the numbers by hart, but I suspect it is the default "while(1)" loop in ROM. If you check the disassembly, I would expect you find it is doing something in line with "loop forever". 

Did you try to define the "nullIsrFunc" and see if that let you catch it? I would expect that the Hwi module might treat it ass a "null ISR" rather than an exception.

Hi M-W,

I tried the nullIsrFunc and I can see that after initialisation is complete (i.e. too late in my Startup.resetFxn) XDC is populating the remaining elements in the vector table in RAM with the address of my function.  However, the first 15 are unchanged.  So it seems like defining that function isn't making a difference to the data that was in flash, but for the ones that were never in flash, this function is used.

It seems odd that when using the RTOS which requires the use of XDC, there's no way to define ISRs for the first 14 interrupts in the vector table.  Is there somewhere else this can be done outside the context of the configuration file?

Hi Hester,

Unfortunately, there is no way of really setting these before initialization. The design is to place only the 15 first vectors in flash and to use the RAM table (which require the initialization to run). 

You could possibly do a change to the XDT files that generate this structure, keep in mind that this is not supported and you would need to verify the functionality. To do this, locate the XDT file, Hwi.cdt, found in (for example) C:\ti\simplelink_cc13x2_26x2_sdk_3_40_00_02\kernel\tirtos\packages\ti\sysbios\family\arm\m3

Look for ti_sysbios_family_arm_m3_Hwi_resetVectors, there you will find how it is generated by the XDC tool.

Hi M-W,

Thanks for pointing me to that file.  I agree that would get pretty messy and I'm keen to avoid that.

However, I did bump into line 44 of Hwi.xdt where Hwi.nmiFunc is checked to see if it has been defined.

I went out on a limb and added m3Hwi.nmiFunc = "&WatchdogHC" to my config file and can see that it has indeed placed my function into the vector table in ROM!  It is then successfully copied into RAM during initialisation. 

It seems this does exactly what I want, but are you aware of any lurking dangers of doing this?

Thanks,

Hester

Hi Hester,

I actually don't know, I have not played around with it before and I can't say for sure how it would impact other ARM features on a TI-RTOS level. I know the Watchdog is setup as an NMI but I think most drivers is not (and TI-RTOS on the CC13xx/cc26xx device do not depend on for example SysTick). 

Following the same idea, have you tried to see if it is enough to replace the "reservedFunc" call instead of the NMI one? If this would also work, I would assume it to be somewhat "safer" to do as this typically tend to be a "catch all" function to indicate unexpected interrupts.

Hi M-W,

I've tried setting the reservedFunc, and the result is populating each of the "reserved" entries in the vector table in ROM (elements 7, 8, 9, 10 and 13).  This is in line with what I expected from looking through Hwi.xdt. 

As far as I can tell, I can set any of the following vector table entries in this way:

• nmiFunc
• hardFaultFunc
• memFaultFunc
• busFaultFunc
• usageFaultFunc
• reservedFunc
• svCallFunc
• debugMonFunc

The PendSV handler appears to be hard-coded in the Hwi.xdt file and trying to set the resetFunc to anything results in a linker error "entry does not match previous occurrence" which isn't too surprising.

I've run my application all the way through from initalisation to shut down, which performs various Bluetooth communications and therefore relies on the RTOS.  If I check the RAM vector table I can still see the same data that I saw at main, including my own nmiFunc address.  I'm rather naively assuming that means it's all fine but I'm not sure how I can prove this.  

Thanks,

Hester

Proving anything is always the hard part, right? :)

This is why I asked if you could test out the reserved function instead. I would assume it placed all the "reserved" entries in the vector table, I was curious to know if this function was invoked as part of the "Unexpected ISR" error.

As I would guess you do not use SysTick (or the Watchdog driver, as that is what this whole thing is about), you might be OK on the NMI part. I suggest you try to figure out from the TRM. As far as I can tell, the WD is really the only driver of the NMI interrupt (which I guess would mean that it is exactly what you want it to be).

Hi Hester,

I would trust the conclusion of that thread :) 

In that case, thank you for your continued support :)