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
Handling of 40bit values in Sharc
Started by ●January 29, 2004
Reply by ●February 12, 20042004-02-12
Reply by ●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-jI'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 ●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, > AndorI 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 ●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 ●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, > > AndorThanks, Bernhard -- before sending to the above email-address: replace deadspam.com by foerstergroup.de
Reply by ●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 ●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
