Community
Participate
Working Groups
In xdctools 3.25.00.48, the Platform Wizard doesn't recognize evm6670 as a base platform that could be imported when the selected device is TMS320C6670. The only platform offered is evm6614, which uses TMS320C6614. Here is the forum thread: http://e2e.ti.com/support/embedded/bios/f/355/t/267800.aspx The following entry shows up in the error log, while running the Platform Wizard. It may or may not be related, the referenced package is 'ti.catalog.arm', which doesn't contain anything related to TMS320C6670. There could be a problem with my CCS5.4 installation. !ENTRY org.eclipse.rtsc.xdctools.ui 4 0 2013-05-31 10:30:01.089 !MESSAGE Invalid module:ti.catalog.arm. !STACK 0 java.lang.NullPointerException: Invalid module:ti.catalog.arm. at org.eclipse.rtsc.xdctools.ui.reflect.Reflect.getInterfaces(Unknown Source) at org.eclipse.rtsc.xdctools.ui.wizards.platform.DevicePage.getDeviceParent(Unknown Source) at org.eclipse.rtsc.xdctools.ui.wizards.platform.DevicePage.checkPlatform(Unknown Source) at org.eclipse.rtsc.xdctools.ui.wizards.platform.DevicePage.getPlatforms(Unknown Source) at org.eclipse.rtsc.xdctools.ui.wizards.platform.DevicePage.access$9(Unknown Source) at org.eclipse.rtsc.xdctools.ui.wizards.platform.DevicePage$10$1.run(Unknown Source) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4144) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3761) at org.eclipse.jface.operation.ModalContext$ModalContextThread.block(ModalContext.java:173) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:388) at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:1028) at org.eclipse.rtsc.xdctools.ui.wizards.platform.DevicePage.handleImportPlatform(Unknown Source) at org.eclipse.rtsc.xdctools.ui.wizards.platform.DevicePage.access$1(Unknown Source) at org.eclipse.rtsc.xdctools.ui.wizards.platform.DevicePage$2.widgetSelected(Unknown Source) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:248) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4169) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3758) at org.eclipse.jface.window.Window.runEventLoop(Window.java:825) at org.eclipse.jface.window.Window.open(Window.java:801) at org.eclipse.rtsc.xdctools.ui.wizards.platform.CreateNewPlatformWizard.run(Unknown Source) ...
The problem is in the platform ti.platforms.arm. We extract a device from each platform and then we check if that device is compatible with the device selected by the user for the new platform. However, ti.platforms.arm specifies an empty string as a device name, which causes a null pointer and the whole process aborts. I added a temporary fix that simply ignores such platforms, but there are cases when such platforms should be added to the list.
Can we use null instead of '' for such platforms?
The current fix is in oerx.ui.reflect.Reflect.java, in getInterfaces(). The function DevicePage.checkPlatform() extracts a device name from a platform's spec and passes a string constructed from the catalog name and the device name to DevicePage.getDeviceParent(). The string is then passed to Reflect.getInterfaces() to get all interfaces that the device catalog module inherits from. Previously, if the device name was an empty string, getInterfaces() wouldn't be able to find the module and it would throw an exception that would abort the platform search. In the current fix, getInterfaces() returns an empty list in such a case, which then causes checkPlatforms() to report no match for that platform, and the platform search continues. In retrospect, a better solution could be for XDCUtils.getExeContextParams to return null for empty module name to checkPlatform, and then checkPlatform wouldn't even call getDeviceParent. Instead, it would jump to returning a false match immediately. The current solution works too, but I am plannning to implement and test that different solution once 3.25.02 is out.
=========verifypass============ This is fix verified in xdcprod-r69
shipped in 3.25.02.70.
