trouble trying to debug c code on MicroBlaze

At the date :2005-06-10 06:37:51 I sendt out a message with the subject: A lot of trouble when trying to debug c code on MicroBlaze.

I am really stucked there and I have not fixed the problems yet nor got any help, so in relation to that problem I will ask some more questions.

A short description on my problem first: If I use XMD - Software debugger or debugging by SDK the debugger seams to go out of scope when I am about to enter a function, but this happends quite randomly. It is not all the time at a particular function. An other problem I have is with the UartLite low level driver.

Q1. If I use the function XUartLite_RecvByte in the function main it seams to work, but if I use it in a subfunction it does not work. I know it is easy to "look blind" at c-code some times so I cant comment on that, other that I have tried many times in various ways. Have anyone experienced that kind of problem before? How did you solve it?

Q2. After reseiving the right commandbyte I have a forloop with

1024 iterations where I send a pulse on one GPIO and read 16 bit data from GPIO. (The data is taken from a fifo outside the MicroBlaze but inside the chip.) When that is done I try to send 2048 bytes of data on the UartLite, but not a single byte is sendt. Again, It is easy to "look blind" on c-code but here is no kind of while loops, only for loops. This means that if I put a breakpoint after the functions the debugger should sooner or later stop at the breakpoint but it does not. It goes out of scope. Have anyone had simmilar problems before? What did you do to fix it?

Q3. The debugger seams unstable. If I go through the (most of the) code once and later tries to run to a breakpoint through code that is finnish debugged, the debugger goes out of scope. If I step through safe earlier debugged code it might get out of scope at a function. The functions generally contains GPIO only and no loops. Is the GPIOs or debugger unstable? does anyone have had problems with that?

I use opb_gpio version 3.01.b I use version 7.1 XPS.

Raymond

Reply to
Raymond Bakken
Loading thread data ...

A small Quiz, for C programmers

****** c code starts here ***** temp = docrc(temp2); xil_printf("CRC: %08X\r",temp); temp = docrc(temp2+1); xil_printf("CRC: %08X\r",temp);

xil_printf("\r\n-- 1"); temp = docrc(temp2); xil_printf("CRC: %08X\r",temp); xil_printf("\r\n-- 2"); temp = docrc(temp2+1); xil_printf("CRC: %08X\r",temp); xil_printf("\r\n-- 3");

****** c code ends here *****

the above c program should print "CRC: " how many times? did you guess 4?

wrong! Correct answer is 3 if the code is compiled with microblaze GCC provided by Xilinx, here is the terminal log:

****** terminal log starts here ***** CRC: 53EE6CD2

-- 1CRC: 1142FDE5

-- 2CRC: 53EE6CD2

-- 3

****** terminal log ends here *****

the first printout is defenetly missing. I am not dreaming, another person did verify the c code and terminal print.

This is exactly the same kind of problem I had with mb gcc llooooong time ago, then I also was forced to add

call_donothing_bullshit();

in some places of my code! thoes where really dummy call's but without them the code did not work.

I did expect this kind of problem not to exist any more. But now I dont wonder any more why John Williams can not use EDK 7.1 GCC for uClinux compiling, if such type of bugs exist I would be real surprised if the compiled linux kernel would work

Antti PS I will ZIP the full project archive and send to some Xilinx personel if they are interested, but I am not opening a webcase. Even if the webcase management takes only 30 minutes of my time. I dont have that time right now (to be wasted).

Reply to
Antti Lukats

"Antti Lukats" schrieb im Newsbeitrag news:d8jrvf$7nv$00$ snipped-for-privacy@news.t-online.com...

them

now

SORRY - I was about to start a new thread so I picked up a random news hit reply and forgot to change subject properly so my news appeared as followup. this was un intentianal.

but the posting I happened to reply was also about problems with microblaze and debug.

just before seeing this 'missing' print I also noticed some weird behaviour in simulator, but I was testing SDRAM so maybe this was something with the caches, dont know, but i did get different readings from cached sdram area until it was all reading 00000, but initially it was filled with xilinx memory tesst and I only did reads in XMD

antti

Reply to
Antti Lukats

It prints 4 but you see 3 ;) \r on the serial line acts are "return to begin of line", without starting a new line. The other 4 works because there is a \n in the intermediate printf with the numbers.

Sylvain

Reply to
Sylvain Munaut

gosh thanks! this time you are right silly me, but the other case was true well it was with EDK 3.2 back looong time ago. ah possible I need some rest being working too hard

antti

Reply to
Antti Lukats

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.