EVMDM642 PCI problem

To summarize:

Your Linux-based code can access the DM642 memory, writes and reads, and these have been verified by examining the DSP's memory.
When you do an ioread() on the Linux-based code, the PC crashes.
Therefore the DSP is doing something wrong.

I do not follow the logic that leads you to "know" that something is wrong with the DSP. It certainly must be included in the list of possibilities, but I recommend you look a bit closer at some of the evidence.

What Linux commands are using to access the memory window and the I/O ports (DSPP) which are working correctly?

Can you examine the PCI bus activity to find out if the ioread() command is toggling the right signals at the DSP and how the DSP is responding back (or not responding)?

The fact that the memory reads and writes are working means that the DSP's PCI peripheral is alive and well. The mechanisms for different PCI command types may require different handling or different addressing methods, so care must be taken to make sure these are configured right.

Randy,

Yes, I get your point, but what I didn't say was that I have a .out image that runs on the board with the same linux driver and there are no problems with it - i.e. the PC doesn't crash when the driver tries to access the memory mapped registers, there is no problem accessing the card and DMA transfers across the PCI bus work fine etc.. 

Unfortunately I lost the source to this code when my windows laptop that I was using for CCS accidentally flew down the stairs and smashed, and I didn't have a backup, just happened to have a copy of the .out file on a memory stick. Therefore I have had to start again and it is my new DSP code that doesn't work, the linux driver is identical, that's why I'm saying there is a problem on the DSP side.

Looking at the PCI registers etc. with JTAG, there is no difference as far as I can see with the PCI and EMIF setup with either image so it's puzzling. 

Maybe you're right and I'll have to get the logic analyser out ...

Cheers, Phil

Ah, the Stairwell Anti-Source Syndrome. I remember a college project where we protected eggs from the SAS Syndrome, so why can we not do the same with laptops? <sad, ironic, smiley face>

The ofd6x utility, which I believe is available under Linux, allows you to extract any and all information from a .out file into a .xml file, and there are Perl scripts (and compiled versions of those) that further filter the information to get symbols or call graphs or such. This could be helpful in trying to recreate the source code that generated the .out file.

I make the assumption that your Linux-side accesses to the DSP's registers do not require any DSP code to be executing, such as interrupt handlers or handshaking for signalling. If this is true, then once the DSP has done all of its configuration and initialization and is ready to run its application, it should be able to go into an infinite loop and let the Linux-side do its accesses without interference. The main point of this is that the state of the PCI peripheral should be the same with both your old .out and your new source .out, and this should be the only requirement for getting the same behavior.

If you only have one DSP on the PCI bus, the EEPROM initialization should not have any effect on this. There is not a lot that would have an effect on this, but obviously something does. Is the PLL set to get the DSP running at the right speed. This is probably done by the DSP code that gets downloaded or by the boot ROM. After that, it should be a matter of looking at all of the PCI-related registers to figure out what could be different.

On the Linux side, the ioread() function has a problem because it should be much more robust than to crash when a read error occurs. That is not directly related to the issue of what causes the read error, but certainly something to look into for the future.