Reply by Andor February 17, 20042004-02-17
Bernhard Holzmayer wrote:
> I found an error in the VDK::PendSemaphore() method: > register R3 (and maybe others) are modified through the call > However, the compiler relies on this register. > This error seems to occur only if optimization is on, thus a > possible workaround (if acceptable) would be to switch optimization > off.
The joys of using RTOSes! Thanks for the update, Bernhard. Good luck, Andor
Reply by Bernhard Holzmayer February 17, 20042004-02-17
Just a resume of my further investigations (to Andor and who else 
may be interested...):

I found an error in the VDK::PendSemaphore() method:
register R3 (and maybe others) are modified through the call
However, the compiler relies on this register. 
This error seems to occur only if optimization is on, thus a 
possible workaround (if acceptable) would be to switch optimization 
off. 

The other observations (of sudden changes in registers) might be 
related to emulator and/or hardware iissues.
Either they happen rather frequently - or they don't happen at all.
If they happen, this seems to indicate an ill-state of the processor
or the emulator/debugger.

I'm not sure why this all happens. 
I guess that stack corruptions or such a thing lead to the 
misbehaviour.

Power-cycling of the board together with a Windows restart on the
IDDE station recovers the scene.

Bernhard
Reply by Bernhard Holzmayer February 13, 20042004-02-13
Andor wrote:

> Bernhard Holzmayer wrote: > ... >> I agree, it's a tough thing. It's even more complex, because I >> integrated VDK, which inserts a third level ('kernel mode'). >> >> Interrupt service routines aren't active during my kernel mode >> routine which is under suspect. >> Except the emulator interrupt, which is opaque to the single >> stepping. >> If another interrupt would have occurred, I'd have seen its >> commands occur in the window. >> >> It seems to be some hardware- or driver-related issue. >> Especially, because I cannot watch these effects always, they >> seem to be >> depending on the "esoteric state" of the complete system... > > I think the correct term is "holistic state". It is known to be > influenced by current load on the electricity company, the length > of yesterday's party you went to and sun spots ;).
I watched dependencies of no of resets and off-time when power-cycling, too. But that depends, usually it's worse on Friday and somehow recovers a bit until Monday...
> > Anycase, I would avoid single stepping whenever possible for > debugging (seeing those altered registers could still be an effect > that happens only during single stepping).
There are other effects concerning I/O behaviour (no samples or so), which I already marked as irrelevant bc. they have certainly to do with interrupting DMA processes etc. Maybe these effects are related to emulator issues and wouldn't occur during normal execution mode.
> Use constants instead of m0.
I changed this already, where possible.
> Check all DAG registers against explicit addresses before > using them, and set breakpoints if those checks fail.
That's a valuable hint.
> > If that doesn't lead to a result, start with very simple programs > (no VDK), and add program complexity until you start seeing > unwanted effects. Perhaps this gives you a clue as to what is > happening.
> > Another idea is to try to take somebody else's EZ-Kit (ask your > distributor to lend you one) and see if you have the same problems > - this should decide if anything is wrong with your hardware.
That's what I'll do, maybe next week.
> > FWIW, > > Andor
Thanks, Bernhard -- before sending to the above email-address: replace deadspam.com by foerstergroup.de
Reply by Andor February 12, 20042004-02-12
Bernhard Holzmayer wrote:
...
> I agree, it's a tough thing. It's even more complex, because I > integrated VDK, which inserts a third level ('kernel mode'). > > Interrupt service routines aren't active during my kernel mode > routine which is under suspect. > Except the emulator interrupt, which is opaque to the single > stepping. > If another interrupt would have occurred, I'd have seen its commands > occur in the window. > > It seems to be some hardware- or driver-related issue. Especially, > because I cannot watch these effects always, they seem to be > depending on the "esoteric state" of the complete system...
I think the correct term is "holistic state". It is known to be influenced by current load on the electricity company, the length of yesterday's party you went to and sun spots ;). Anycase, I would avoid single stepping whenever possible for debugging (seeing those altered registers could still be an effect that happens only during single stepping). Use constants instead of m0. Check all DAG registers against explicit addresses before using them, and set breakpoints if those checks fail. If that doesn't lead to a result, start with very simple programs (no VDK), and add program complexity until you start seeing unwanted effects. Perhaps this gives you a clue as to what is happening. Another idea is to try to take somebody else's EZ-Kit (ask your distributor to lend you one) and see if you have the same problems - this should decide if anything is wrong with your hardware. FWIW, Andor
Reply by Bernhard Holzmayer February 12, 20042004-02-12
Andor wrote:

> Bernhard Holzmayer wrote: > ... >> While single stepping through my code, yesterday, I could see (in >> the emulator windows) that different registers change their >> values without obvious reason. >> Concerned registers were i0, i8, m0 (and maybe others which I >> wasn't aware of). > > I have an 21161N EZ-Kit and never had any such problems. Single > stepping a real-time system is not trivial. Perhaps some interrupt > routine modified those registers? > > Regards, > Andor
I agree, it's a tough thing. It's even more complex, because I integrated VDK, which inserts a third level ('kernel mode'). Interrupt service routines aren't active during my kernel mode routine which is under suspect. Except the emulator interrupt, which is opaque to the single stepping. If another interrupt would have occurred, I'd have seen its commands occur in the window. It seems to be some hardware- or driver-related issue. Especially, because I cannot watch these effects always, they seem to be depending on the "esoteric state" of the complete system... Would have been encouraging (??) to know that somebody else suffers from the same failures... Nevertheless, I keep watching out for failures in my implementation. Bernhard
Reply by Bernhard Holzmayer February 12, 20042004-02-12
robert bristow-johnson wrote:

> In article 4681792.CG0xz0DKgh@holzmayer.ifr.rt, Bernhard Holzmayer > at holzmayer.bernhard@deadspam.com wrote on 02/11/2004 02:56: > >> While single stepping through my code, yesterday, I could see (in >> the emulator windows) that different registers change their >> values without obvious reason. >> Concerned registers were i0, i8, m0 (and maybe others which I >> wasn't aware of). >> >> The registers weren't actively used, I mean, they didn't >> participate in the current or previous/next commands to process. >> So, it's certainly not an issue of contents of Lx or Bx >> registers. > > it's not exactly germane to your problem, but one thing that has > always bothered me about the SHArC is that, if your interrupt > service routine saves and restores the 40 bit floating-point > registers in normal (32 bit) memory, the bottom 8 bits can get > spuriously trashed in the middle of an FIR > summation or similar obviating the use of those bottom 8 bits. of > course there are work arounds (alternate register set, declaring > F12-F15 off limits > to ISRs, etc.). it's just an inelegant thing. > > r b-j
I'm aware of these effects - and, yes, I have to deal with them. The modifications which I mentioned, are like these: register m0 (which was '0') changed to '1' register i8 (which was '0x43a04') changed to 0x409c0 Hasn't to do with 40bit extensions, I guess. Bernhard
Reply by robert bristow-johnson February 12, 20042004-02-12
In article 4681792.CG0xz0DKgh@holzmayer.ifr.rt, Bernhard Holzmayer at
holzmayer.bernhard@deadspam.com wrote on 02/11/2004 02:56:

> While single stepping through my code, yesterday, I could see (in > the emulator windows) that different registers change their values > without obvious reason. > Concerned registers were i0, i8, m0 (and maybe others which I wasn't > aware of). > > The registers weren't actively used, I mean, they didn't participate > in the current or previous/next commands to process. > So, it's certainly not an issue of contents of Lx or Bx registers.
it's not exactly germane to your problem, but one thing that has always bothered me about the SHArC is that, if your interrupt service routine saves and restores the 40 bit floating-point registers in normal (32 bit) memory, the bottom 8 bits can get spuriously trashed in the middle of an FIR summation or similar obviating the use of those bottom 8 bits. of course there are work arounds (alternate register set, declaring F12-F15 off limits to ISRs, etc.). it's just an inelegant thing. r b-j
Reply by Andor February 11, 20042004-02-11
Bernhard Holzmayer wrote:
...
> While single stepping through my code, yesterday, I could see (in > the emulator windows) that different registers change their values > without obvious reason. > Concerned registers were i0, i8, m0 (and maybe others which I wasn't > aware of).
I have an 21161N EZ-Kit and never had any such problems. Single stepping a real-time system is not trivial. Perhaps some interrupt routine modified those registers? Regards, Andor
Reply by Bernhard Holzmayer February 11, 20042004-02-11
I should have added,
that my confusion started when I watched wrong values while checking 
an algorithm's implementation.

I guessed that these wrong values must have their origin in the area 
of 40bit processing. Then I got trapped in this initialization 
stuff.

However, although these issues are solved, I still end up with 
errors during the algorithm.

While single stepping through my code, yesterday, I could see (in 
the emulator windows) that different registers change their values 
without obvious reason.
Concerned registers were i0, i8, m0 (and maybe others which I wasn't 
aware of).

The registers weren't actively used, I mean, they didn't participate 
in the current or previous/next commands to process.
So, it's certainly not an issue of contents of Lx or Bx registers.

This might be an explanation why my algorithm did fail:
when I fetched data from memory with a wrong index or modifier 
register, I'd have certainly ended up with messy data.

My question:
Is there anybody out there who suffered/suffers from the same 
problems with Sharc DSPs / EZ-Lite boards ?

Are there any experiences and/or maybe solutions?

I wonder if it's a hardware issue, maybe my USB cable is too long,
or the ground potentials of the different connections raise 
instabilities.

Any ideas welcome.

Bernhard  



 

Reply by Bernhard Holzmayer February 10, 20042004-02-10
Andor wrote:

> Bernhard wrote: >> Hi Andor, >> >> meanwhile I started from scratch, trying to set 40bit processing >> up. I succeeded to read data from 40bit internal ram, get it into >> registers and out again into 40bit IRAM. >> Still, working with external SDRAM fails. >> >> Below is a short portion of sample code which should contain >> everything necessary. Would you please have a look on it, >> if anything obvious is wrong?? > > I don't see anything wrong at first glance. Make sure you have set > up the SDRAM for 48bit access and not for 32bit access (check out > the 21161N and the EZ-Kit manuals for the relevant registers). > > > Regards, > Andor
Thanks Andor, for checking. Yes, that's it, a wrong initialization of the SDRAM while loading the coefficients. I didn't see it at first glance, because the emulator hides the effect: after resetting and before reloading code and initialization values, it switches back to 32/48bit mode, thus initialized values are in wrong locations. However, when loading from Flash, it works bc. I'd inserted the SYSCON modification into the prom loader. Removing the flag (Target options...) which resets the processor, made the emulator behave as it should. I should have known, bc. I dealt with the issue one year ago, ... Bernhard