more microblaze firmware blues. tool chain version problem?

Hi all, I am currently working on porting some code on microblaze from a spartan 3 FPGA to a virtex 2 pro FPGA for expansion reasons. The code which really works on a spartan 3 FPGA, just somehow does not seem to work on the virtex 2 pro. Here are some details:

1) for the spartan 3 FPGA, I used both EDK9.1i+ISE 7.1i and EDK9.2i +ISE9.2i the same firmware running on the spartan works fine. 2) I ported exactly the same architecture + firmware + EDK9.1i, since EDK9.2i does not support virtex 2 pro yet. which is really disappointing 3) my hardware architecture is like this; the hardware peripherals are

when using EDK9.2i and spartan 3

- microblaze v7.0 with plb bus

- a UART peripheral, modified to perform hardware handshaking

- this works fine

when using EDK7.1i and spartan 3

- microblaze v4.0 with opb bus

-a UART peripheral, modified to perform hardware handshaking

- this works fine

when using EDK9.1i and virtex 2 pro

- microblaze 6.0

- a UART peripheral, modified to perform hardware handshaking

- this does not work, the algo does not return correct data at all.

4) my software design flow looks like the one below. No interrupt is used.

int main(){ get_params(); //get data from UART using blocking statements start_algo(); //to start algo return_result(); //return results back to PC via UART. }

void start_algo(){ // I inserted a breakpoint around here. ...the rest of the algo.... }

5) I have tested that int main(){ get_params(); //get data from UART using blocking statements return_result(); //return results back to PC via UART. }

works. So the problem is not with the UART data transfer.

6) how i know it does not work a) wrong data is sent back from the virtex 2 pro board back to PC. b) when I sent the compilation switch to no optimisation, the problem gets worse. No data is sent back at all to PC. again to iterate, the same firmware works on spartan 3, using EDK9.2i (microblaze 7) and EDK7.1i (microblaze 4). now, it does not work on EDK9.1i (microblaze 6).

if things are not already bad enough, when doing debugging using the mdm hardware debugger, stepping sometimes already results in the program jumping to some other routine that does not correspond to the software flow. I am equally cluelss about this.

this subject is related to one that i posted 2 weeks ago. the topic is "microblaze firmware + UART handshaking blues"

I have modifed to make sure that the stack size is 0x1000. What else could have gone wrong?

any help on this will be greatly appreciated.

thanks a million. Chris

Reply to
chrisdekoh
Loading thread data ...

you are not the only one having GCC/UART/EDK blues

1) with some GCC version it has been necessarry to add

call_some_really_dummy_do_nothing();

2) sometimes it is needed to add

wait_some_real_time();

at the start of main() or first UART output will not appear

3) if using EDK 9.1 then if the BRAM is made up of 2 or more BRAM blocks then there is no tool error reported, but the second BRAM does not get initialized with code, so if the algorithm spans into second BRAM it will fail with different behaviour depending on optimization setting

4) some other issues are also possible of course

5) 6)..

Antti Lukats

Reply to
Antti

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.