I was trying to get one of my controller PCs to talk to one of the hardware units we are developing. The hardware unit is a complex mixture of video processor hardware and controlling software. It runs VxWorks and was trying to find the controller PC by IP. The PC could ping most of the IPs external/internal to the subnet but could not ping the hardware unit. And the hardware unit could everything but this particular PC.
The IT guy came around and tried loads of different things including nameserver settings, installing drivers and physical cable checks. I thought this could be a router problem. But apparently there was no router between these two machines.
After much wasted hours and sanity, he decided to replace the NIC. And that was that. It was a faulty NIC which worked for most things other than pinging my hardware unit. Strange.
Tuesday, May 23, 2006
Friday, May 19, 2006
GEL file mystery
GEL stands for General Extension Language. That's a vague enough description. It's an interpreted language similar to C. This language consists of a list functions that could be used to configure the Code Composer Studio Development environment. They can also be used to initialize the target DSP by emulating the host processor command interface functionality. When you set up the Code Composer Studio (CCS), you can specify a start-up GEL for each of the DSPs you have on your board. When the CCS starts up, it loads the GEL files on to the PC's memory that CCS runs and if it contains a StartUp(...) function, the code withing that function is executed.
This function could have code to describe te DSP memory map, configure EMIF registers etc., . The StartUp(...) function can be used to initialize the target DSP as well as the host ( this case it's the CCS). In later versions (v2.4 and higher) CCS doesn't connect to the target board on start up. The user has to manually connect to the target using Debug/Connect menu. There's a function callback called OnTargetConnect(...) which would be called by the CCS when it connect to the target(1). You can put all the target initialization code in there.
So what is this host processor we are talking about here?
In a typical DSP development there's a host processor which controls the DSP. And this host processor configures the DSP for program loading and execution. When the program executes, usually it will feed the DSP with data and suck some other data out of DSP memory space. Basically the host processor keeps the DSP in order. All this is done through the HPI [ Host Processor Interface ]
The HPI is a parallel port through which the host processor can directly access te DSP memory space. This access can be through a DMA or a EDMA controller. Host device functions as a master to the HPI and the host and the DSP can exchange data through internal or external memory. Host also has direct access to memory mapped peripherals(2).
The good thing about this, is that while the processor team are busy developing the electronics for the host processor, the DSP team can concentrate on developing the algorithms for the DSP (3). Once you get your board from the processor dev team, you'd want to run your code on the board under CCS. GEL file comes to aid in this situation by letting the CCS emulate the task of the host processor. You can connect to your board, compile and load the program through CCS. But sometimes if you have not configured the EMIF [External Memory Interface] settings properly you could get an error message like, "Data verification failed at address 0x... Please verify target memory and memory map". This is rather misleading error message but what goes on here is that the CCS writes the data on to the target board's memory and then runs a verification to see if the data write was successful. But when the wrong EMIF settings are there it can't access the external properly, and thus the error message.
In this case the most important part is the emif_init(...) function, where you set the EMIF settings.
You have to acquire the proper settings from the processor development team how they have connected the memory and timings and such. Once you have the correct settings the CCS happily loads the program on to the target DSP and it would be ready to run under CCS.
References:
(1)Creating Device Initialization GEL files
http://focus.ti.com/lit/an/spraa74a/spraa74a.pdf
(2) TMS320C6000 DSP Host Port Interface (HPI) Reference Guide
http://focus.ti.com/lit/ug/spru578c/spru578c.pdf
(3) Using GEL file for parallel development and testing of DSP applications
S. Jaisimha, Singapore Design Engineering Centre, Delphi Delco Electronics Systems
http://www.embeddedstar.com/articles/2004/2/article20040209-1.html
This function could have code to describe te DSP memory map, configure EMIF registers etc., . The StartUp(...) function can be used to initialize the target DSP as well as the host ( this case it's the CCS). In later versions (v2.4 and higher) CCS doesn't connect to the target board on start up. The user has to manually connect to the target using Debug/Connect menu. There's a function callback called OnTargetConnect(...) which would be called by the CCS when it connect to the target(1). You can put all the target initialization code in there.
So what is this host processor we are talking about here?
In a typical DSP development there's a host processor which controls the DSP. And this host processor configures the DSP for program loading and execution. When the program executes, usually it will feed the DSP with data and suck some other data out of DSP memory space. Basically the host processor keeps the DSP in order. All this is done through the HPI [ Host Processor Interface ]
The HPI is a parallel port through which the host processor can directly access te DSP memory space. This access can be through a DMA or a EDMA controller. Host device functions as a master to the HPI and the host and the DSP can exchange data through internal or external memory. Host also has direct access to memory mapped peripherals(2).
The good thing about this, is that while the processor team are busy developing the electronics for the host processor, the DSP team can concentrate on developing the algorithms for the DSP (3). Once you get your board from the processor dev team, you'd want to run your code on the board under CCS. GEL file comes to aid in this situation by letting the CCS emulate the task of the host processor. You can connect to your board, compile and load the program through CCS. But sometimes if you have not configured the EMIF [External Memory Interface] settings properly you could get an error message like, "Data verification failed at address 0x... Please verify target memory and memory map". This is rather misleading error message but what goes on here is that the CCS writes the data on to the target board's memory and then runs a verification to see if the data write was successful. But when the wrong EMIF settings are there it can't access the external properly, and thus the error message.
In this case the most important part is the emif_init(...) function, where you set the EMIF settings.
EMIF registers
GBLCTL EMIF global control register
CECTL0-3 EMIF CE space control registers
CESEC0-3 EMIF CE space secondary control registers
SDCTL EMIF SDRAM control register
SDTIM EMIF SDRAM refresh control register
SDEXT EMIF SDRAM extension register
PDTCTL EMIF peripheral device transfer control register
You have to acquire the proper settings from the processor development team how they have connected the memory and timings and such. Once you have the correct settings the CCS happily loads the program on to the target DSP and it would be ready to run under CCS.
References:
(1)Creating Device Initialization GEL files
http://focus.ti.com/lit/an/spraa74a/spraa74a.pdf
(2) TMS320C6000 DSP Host Port Interface (HPI) Reference Guide
http://focus.ti.com/lit/ug/spru578c/spru578c.pdf
(3) Using GEL file for parallel development and testing of DSP applications
S. Jaisimha, Singapore Design Engineering Centre, Delphi Delco Electronics Systems
http://www.embeddedstar.com/articles/2004/2/article20040209-1.html
Subscribe to:
Posts (Atom)