actually I try to find some issue in my code with breakpoints, as usual. (I wrote the code to run other systems too, and theres no problem).
My system contains lib_sdram (new) and xTimecomposer 14.0.3.
When the xmos stops on a breakpoint, lib_sdram hangs on ET_ILLEGAL_RESOURCE on
issue WE term signal. (it is on the read() breanch by the way...)
Problem 1) right now, I dont care on this part of the code, I debug on some other thread/core. But on each steps this same signals occures. Yes, Iam understand it is because of the other tread not feed / locks the buffer swich mechanism, and probably the code is not wrong here... (this part is ok)lib_sram/src/io.S 148:
//load the ports
ldw ras, r1[2] //ras
ldw we, r1[3] //we
ldw dq_ah, r1[0] //dq_ah
//issue the we term signals(non-blocking)
setpt res[we], term_time
ldc temp, 2
outpw res[we], temp, 2
b
Q1)
Is it possible to ignore/skip/stop this behavior ? (I can comment out the whole hw access of this task , but... eh..)
xTimeComposer have a context menu item: "Resume Without Signal"
As far as I seen, it doesn't do what I think :).
Problem2) Actually I have no time to do measurements of the sdram bus, but I have some issues w this too earlier. So rearly the lcd screen goes to green and only w green lines shown . In this case, the lcd outputs was right basically, but xmos sent not the right framebuffer datas there. The timing (change periods of the signal levels) was similar than the sdram refresh (WE,RAS,CAS). Meenwhile the sdram refresh signals was stacked. So there was not an acceptable datastream or refresh command... I was using analyzator to measure what happend. And I seen the right and the wrong situations... So, I dont understand exactly what was this, but I think there is some reason is the code. (deadlocks, etc)
Q2) Any ideas? Similar situations?
a) I can imagine, if my buffer feeder code :) was overwritten something, because it is C/C++...
b) there is some thermal / working conditions relating to similar issues? Because yes, the chip was not cold as usual... So I can imagine, if the SDRAM and xmos was driving the same data lines because of the situation...
Problem3) Some of the new libraries (lcd+sdram and ethernet slice libs) not run in debug mode for me.
Q3)
a) If I compiled with -O0, I got only solid or blinking red lcd. I did not measure the signals. Theres no exceptions/signals, or any sign of a trivially wrong condition for first sight.
b) This is only because the non-optimalized code is to slow for pixel clock?
c) Or how can I compile this libs in debug mode?