UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor abekas
Visitor
2,430 Views
Registered: ‎06-29-2010

SP605 MPU Read From System Ace Problem

I'm using a PicoBlaze to read LBA blocks from a CF on an SP605 board.

I've been over everything *very* carefully.

All status, flags etc returned over the MPU port are correct. The CF I'm using is the one that came with the board and will JTAG the board ok so I'm pretty sure the hardware is ok.

When I read LBA0 from the MPU port (the boot block) I get very consistant but garbage data. I can't see any correlatio

n with what is in the boot block except the wierd thing is that the last two bytes of the 512byte boot block are correct (0x55, 0xAA).

As the flags/error stat are correct I'm nearly certain the read is correct. The DATABUFRDY does exaclty the right thing as the 32 byes are unstuffed from the fifo. The other odd thing is that the FATSTATREG is always 0x0. The data sheet (DS080 v2.0) does not say when this is loaded.

I am not sure what to do next. Obviously other people must have used the MPU port.
Do you have any ideas? Perhaps sample code from a Linux or Blaze driver for this.
The fact that that data is always the same but wrong and the last two bytes are correct for sector 0 is a bit puzzling
0 Kudos
1 Reply
Highlighted
Visitor gederer
Visitor
2,169 Views
Registered: ‎01-24-2011

Re: SP605 MPU Read From System Ace Problem

Not sure what you were comparing the boot sector to? Did you compare with a windows tool. 

 

Possibly you were comparing the MBR (sector 0) with the PBR (partition boot record which is not sector 0).

Windows or linux might might read sector 0 of a partition at the PBR, not the MBR. Therefore different but consitent data, and also you see the 0x55 0xAA signature.

0 Kudos